Challenges and directions for optimizing the automated solution of the general MPC problem

Vladimir Kolesnikov ( Bell Labs ) Tal Malkin ( Columbia U ), Payman Mohassel ( U Calgary ), Mike Rosulek ( Oregon State ), Yehuda Lindell ( Bar-Ilan U ) Kedar Namjoshi, Alan Jeffrey, Steve Fortune ( Bell Labs )

Outline

• Problem description • Protocol composition for performance improvement • Leakage for insane performance improvement But what guarantees do we have?

• Research directions in cryptography, compilers and program analysis • Heilmeier’s Catechism 2

General MPC

• One button to generate the best protocol • High-level language?

• Program may specify (partial list) Number of players Trust assumptions Communication channel assumptions Player computational abilities Leakage allowance Automatically or manually select: The “right” subroutine E.g. Array implementation via GC or ORAM 3

(Automatic) Subroutine Selection & Protocol composition

• Crypto primitives for variety of general and special cases GC, Info-theoretic GC, GMW, ORAM, ORAM-based MPC Server-aided computation OBDD, FSA Homomorpic … • Each is best in some setting 4

(Automatic) Subroutine Selection & Protocol composition (cont.)

• Crypto primitives for variety of special cases • Idea: compose (automatically or manually) the “right” subroutines.

Few first attempts [KSS13] (GC + homomorphic, manual), TASTY [HSSW10] [LHSHK14] (GC+ORAM, compiler), “order of magnitude” improvement • GC can serve as secure “glue” for many compositions In the semi-honest model. Much harder in malicious model.

• Systematize the approaches • Amend/design protocols to enable easy composition 5

Leakage

• Much of the cost of MPC comes from “the last mile” Selective abort allows to learn one bit at the cost of being caught Cost: complex Cut-and-choose with s^2 commitments Dual execution [MF06] leaks one bit at the cost of being caught Cost: 20x performance overhead via [Lin13] Leaking execution path in large-input computation (e.g. [PKVKMCGKB14]) Cost: insane (vs GC), orders of magnitude (vs ORAM-MPC) • In deadline-driven applications, the choice is between no privacy / imperfect privacy Imperfect privacy can be more dangerous if not clearly understood 6

Research directions – MPC improvements & Benchmarking

Research in improving standalone protocols, with a view of composition General Specific functions Implementations Profiling frequently-used primitives a-la OT Extension[ALSZ13] Specific to settings (high/low power devices, battery considerations, etc.) 7

Research directions – Composition

• Systematize the many approaches • Amend/design protocols to enable easy composition at compile-time • Malicious model composition • Compiler work to automate primitive selection and gluing 8

Research directions – Leakage

• Design faster and less-leaking protocols Improve bounds and guarantees on Covert protocols Dual execution protocols Other 9

Research directions – Understanding (Composed) Leakage

• Needed even in “proper” non-leaky protocols Multiple execution leaks a complex object that is often hard to understand E.g. What is learned from a sequence of DB queries If running time is also revealed • Design concepts, language, and tools for leakage analysis • New leaky definitions 10

Research directions – Understanding (Composed) Leakage

• Consider a high-level program which calls subroutines (e.g. DB queries) • Use automated program analysis and verification techniques: Trace possible/probable program states and subroutine call sequences Bound the knowledge gained from leakage, malicious gains and legal outputs Answer questions of the type “Is information x leaked?” 11

Heilmeier’s Catechism (1)

• What are you trying to do? Understandable security for deadline-oriented applications • How is it done today, and what are the limits of current practice?

Not done* • What's new in your approach and why do you think it will be successful?

Combination of crypto, compilers, and automated leakage analysis • Who cares?

Agencies who may not share their data; industry if it’s simple and fast enough • If you're successful, what difference will it make?

More PII privacy, ability to securely share data, technological enforcement of data laws.

12

Heilmeier’s Catechism (2)

• What are the risks and the payoffs?

MPC improvements are low- to medium- risk, depending on expectation Leakage analysis is high-risk as a new field Pay off – up to eliminating overhead of MPC (with leakage, in ideal world, in some settings) • How much will it cost?

7-10 people working ½ time • How long will it take?

3-4 years to see noticeable results 13

Heilmeier’s Catechism (3)

• What are the midterm and final "exams" to check for success?

Foundations (1.5 yrs) MPC crypto work in systematization etc.

Design of leakage specification language and analysis tools Demo Implementation of (1.5 yrs) Improve foundations and deliver an implementation Deliverable A push-button system 14

Bibliography

[ALSZ13] Gilad Asharov, Yehuda Lindell, Thomas Schneider, Michael Zohner. More efficient oblivious transfer and extensions for faster secure computation. In Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security.

[HSSW10] Wilko Henecka, Ahmad-Reza Sadeghi, Thomas Schneider, Immo Wehrenberg. TASTY: tool for automating secure two-party computations. CCS 2010 [KSS13] Vladimir Kolesnikov, Ahmad-Reza Sadeghi, Thomas Schneider: A systematic approach to practically efficient general two-party secure function evaluation protocols and their modular design. Journal of Computer Security 21(2): 283-315 (2013) [LHSHK14] Chang Liu, Yan Huang, Elaine Shi, Michael Hicks, and Jonathan Katz. Automating Efficient RAM-Model Secure Computation. In S&P (Oakland) 2014 [MF06] Payman Mohassel, Matthew K. Franklin: Efficiency Tradeoffs for Malicious Two Party Computation. In PKC 2006 [Lin13] Yehuda Lindell: Fast Cut-and-Choose Based Protocols for Malicious and Covert Adversaries. CRYPTO (2) 2013 [PKVKMCGKB14] Vasilis Pappas, Fernando Krell, Binh Vo, Vladimir Kolesnikov, Tal Malkin, Seung Geol Choi, Wesley George, Angelos Keromytis, Steve Bellovin. Blind Seer: A Scalable Private DBMS. In Oakland 2014.

15