general purpose frameworks for secure multi party
play

General Purpose Frameworks for Secure Multi-party Computation - PowerPoint PPT Presentation

General Purpose Frameworks for Secure Multi-party Computation Marcella Brett Daniel Steve Hemenway Hastings Noble Zdancewic University of Pennsylvania 1 / 26 Secure multi-party computation (MPC) MPC allows a group of mutually


  1. General Purpose Frameworks for Secure Multi-party Computation Marcella Brett Daniel Steve Hemenway Hastings Noble Zdancewic University of Pennsylvania 1 / 26

  2. Secure multi-party computation (MPC) MPC allows a group of mutually distrustful parties to compute a function on their joint inputs without revealing anything beyond the output. 2 / 26

  3. Secure multi-party computation (MPC) MPC allows a group of mutually distrustful parties to compute a function on their joint inputs without revealing anything beyond the output. Example: Danish sugar beet auction [BCD+08] Parties: beet farmers, govern- ment buyer, research university Inputs: Beet prices, yields Outputs: Market clearing price 2 / 26

  4. Beyond Beets: MPC in practice Blind auction [BCD+08] 3 / 26

  5. Beyond Beets: MPC in practice Blind auction Fraud detection [BCD+08] [BJSV16] 3 / 26

  6. Beyond Beets: MPC in practice Parameter Blind auction Fraud detection computation [BCD+08] [BJSV16] [BGM17] 3 / 26

  7. Beyond Beets: MPC in practice Parameter Blind auction Fraud detection computation [BCD+08] [BJSV16] [BGM17] Financial statistics [BLV17] 3 / 26

  8. Beyond Beets: MPC in practice Parameter Blind auction Fraud detection computation [BCD+08] [BJSV16] [BGM17] Financial statistics Government Private companies [BLV17] applications 3 / 26

  9. Motivating end-to-end frameworks for MPC Custom one-off solutions are unsustainable 4 / 26

  10. Motivating end-to-end frameworks for MPC Custom one-off solutions are unsustainable Protocols assumed impractical until Fairplay [MNPS04] 4 / 26

  11. Motivating end-to-end frameworks for MPC Custom one-off solutions are unsustainable Protocols assumed impractical until Fairplay [MNPS04] Performance improvements rapidly advanced state-of-the-art OT extension [IKNP03] Free XOR gates [KS08] Half-gates [ZRE15] AES-NI 4 / 26

  12. Modern General-Purpose Frameworks function input function function compiler runtime description output Framework 5 / 26

  13. Modern General-Purpose Frameworks function input function function compiler runtime description output Framework Who are frameworks designed for? What types of cryptographic settings do they use? Are they suitable for use in large-scale applications? 5 / 26

  14. Contributions General purpose frameworks for secure multi-party computation [HHNZ19] Survey Surveyed 9 frameworks and 2 circuit compilers Recorded protocol, feature, implementation details Evaluated usability criteria 6 / 26

  15. Contributions General purpose frameworks for secure multi-party computation [HHNZ19] Survey Surveyed 9 frameworks and 2 circuit compilers Recorded protocol, feature, implementation details Evaluated usability criteria Open-source framework repository Three sample programs in every framework Docker instances with complete build environments Documentation on compilation and execution github.com/mpc-sok/frameworks 6 / 26

  16. Findings Most frameworks are in good shape! Diverse set of threat models and protocols Expressive high-level languages Accessible, open-source, and compilable 7 / 26

  17. Findings Most frameworks are in good shape! Diverse set of threat models and protocols Expressive high-level languages Accessible, open-source, and compilable Room for improvement Engineering limitations Barriers to usability 7 / 26

  18. Frameworks and protocol families H y b r i d t i SCALE-MAMBA u c EMP-toolkit r i Sharemind c Obliv-C d PICCO e ObliVM l b r a TinyGarble G ABY Wysteria M u l t i - p a r t y c i r c u i t d b a s e 8 / 26

  19. Frameworks and protocol families H y b r i d t i SCALE-MAMBA u c EMP-toolkit r i Sharemind c Obliv-C d PICCO e ObliVM l b r a TinyGarble G ABY Wysteria M u l t i - p a r t y c i r c u i t d b a s e 8 / 26

  20. Garbled circuit protocols Introduced by [Yao82, Yao86] function garble evaluate output runtime Functions represented as Boolean circuits Typically semi-honest, 2-party Constant-round communication, volume ∝ circuit size 9 / 26

  21. Frameworks and protocol families H y b r i d t i SCALE-MAMBA u c EMP-toolkit r i Sharemind c Obliv-C d PICCO e ObliVM l b r a TinyGarble G ABY Wysteria M u l t i - p a r t y c i r c u i t d b a s e 10 / 26

  22. Multi-party circuit-based protocols Introduced by [GMW87, BGW88, CCD88] . . . . . . . . . Functions represented as Boolean or arithmetic circuits Data represented as linear secret shares Various threat models and protocol types (information-theoretic or cryptographic) Rounds, volume of communication ∝ multiplication gates 11 / 26

  23. Frameworks and protocol families H y b r i d t i SCALE-MAMBA u c EMP-toolkit r i Sharemind c Obliv-C d PICCO e ObliVM l b r a TinyGarble G ABY Wysteria M u l t i - p a r t y c i r c u i t d b a s e 12 / 26

  24. Frameworks and protocol families H y b r i d t i SCALE-MAMBA u c EMP-toolkit r i Sharemind c Obliv-C d PICCO e ObliVM l b r a TinyGarble G ABY Wysteria M u l t i - p a r t y c i r c u i t d b a s e 12 / 26

  25. Hybrid protocols Integrates optimized subprotocols for common functions Bitwise operators in arithmetic settings Matrix operations Seamless front-end experience (no explicit protocol selection) Currently: One-to-one mapping from operations to protocols

  26. Hybrid protocols Integrates optimized subprotocols for common functions Bitwise operators in arithmetic settings Matrix operations Seamless front-end experience (no explicit protocol selection) Currently: One-to-one mapping from operations to protocols 13 / 26

  27. Frameworks and protocol families H y b r i d t i u SCALE-MAMBA c EMP-toolkit r i Sharemind c Obliv-C d PICCO e l ObliVM b r TinyGarble a G ABY M Wysteria u l t i - p a r t y c i r c u i t b d a s e 14 / 26

  28. Frameworks and protocol families (2019) H y b r i d t i u SCALE-MAMBA c EMP-toolkit r i Sharemind c Obliv-C d PICCO e l ObliVM b EzPC r TinyGarble a G JIFF MP- SPDZ ABY HyCC FRESCO ABY 3 M Wysteria u l t i - p a r t y c i r c u i t b d a s e 14 / 26

  29. Design decisions Architecture: system structure and data representation Circuit model: representing data-independent paradigm Language accessibility: cryptographic abstraction level 15 / 26

  30. Design decisions: Data-independent construction Should designers reveal “non-traditional” performance characteristics? Circuits are a data-independent representation. Branching programs are flattened in this model. Non-expert users might not recognize this performance disparity. 16 / 26

  31. Data independence: Private conditionals Should branching programs reveal atypical performance? Obliv-C: traditional paradigm r e s u l t ; obliv int obliv i f ( a > = b) { r e s u l t = a ∗ a ; } else { r e s u l t = b ; } 17 / 26

  32. Data independence: Private conditionals Should branching programs reveal atypical performance? Obliv-C: traditional paradigm r e s u l t ; obliv int obliv i f ( a > = b) { r e s u l t = a ∗ a ; } else { r e s u l t = b ; } EMP-toolkit: explicit branch selection a b i g g e r = a . geq (b ) ; Bit Integer r e s u l t = b . s e l e c t ( a bigger , a ∗ a ) ; 17 / 26

  33. Data independence: Private conditionals Should branching programs reveal atypical performance? Obliv-C: traditional paradigm r e s u l t ; obliv int obliv i f ( a > = b) { r e s u l t = a ∗ a ; } else { r e s u l t = b ; } EMP-toolkit: explicit branch selection a b i g g e r = a . geq (b ) ; Bit Integer r e s u l t = b . s e l e c t ( a bigger , a ∗ a ) ; Recommendation Depends on your users, but data independence is a good paradigm 17 / 26

  34. Design decisions: Cryptographic abstraction level Should the user have control over the underlying cryptographic representation? Frigate: standard (C-style) abstraction int r e s u l t = 0; for ( int i =0; i < LEN ; i++) { r e s u l t = r e s u l t + (A. data [ i ] ∗ B. data [ i ] ) ; } 18 / 26

  35. Design decisions: Cryptographic abstraction level Should the user have control over the underlying cryptographic representation? Frigate: standard (C-style) abstraction int r e s u l t = 0; for ( int i =0; i < LEN ; i++) { r e s u l t = r e s u l t + (A. data [ i ] ∗ B. data [ i ] ) ; } PICCO: custom primitive, high level abstraction r e s u l t = A @ B; int 18 / 26

  36. Design decisions: Cryptographic abstraction level Should the user have control over the underlying cryptographic representation? ABY: Low-level access share ∗ A, ∗ B; A = c i r c − > PutMULGate(A, B) ; A = c i r c − > P u t S p l i t t e r G a t e (A) ; for ( u i n t 3 2 t i = 1; i < LEN ; i++) { A − > s e t w i r e i d ( 0 , c i r c − > PutADDGate(A − > g e t w i r e i d (0) , A − > g e t w i r e i d ( i ) ) ) ; } A − > s e t b i t l e n g t h ( 1 ) ; share ∗ r e s u l t = c i r c − > PutOUTGate(A, ALL ) ; 19 / 26

  37. Software engineering Complicated, non-trivial build systems Set up certificate authority or PKI Compile specific OpenSSL version from source No dependency lists, manual search for compile errors Estimated time: 1-2 weeks per framework 20 / 26

Recommend


More recommend