Be,er Privacy and Security via Secure Computa9on Jonathan Katz - PowerPoint PPT Presentation

Be,er Privacy and Security via Secure Computa9on Jonathan Katz

Security/privacy would be much easier…

…if there were someone we could all TRUST with our data

Be8er data mining -- using MORE data, while respec@ng users’ PRIVACY

CONTROLLED informa@on sharing

Be8er privacy/security for EVERYONE

Would be nice if there were someone we could all TRUST with our data…

But there isn’t

• Legal / regulatory restric@ons • Not economically viable (cost + liability vs. value) • Central point of failure/a8ack • Incompa9ble trust frameworks

Would be nice if there were someone Would be even be,er if we could AVOID we could all TRUST with our data… the need for trust in the first place!

Secure computa9on ensures: • Confiden9ality – No party’s input is revealed • Integrity – Correct output is computed • Availability – All par@es obtain the output Caveats • Input independence – Each party’s input is independent of the others’

Assump9ons/caveats • Number of malicious par@es (some@mes) • Ac9ons of malicious par@es (some@mes) • Cryptographic hardness (some@mes) • Weaker guarantees (some@mes)

Secure computa@on of any func@on, with security against arbitrary behavior of any number of par@es, is possible

Two-party seRng • Start with a boolean circuit for f • P 1 sends a “ garbled circuit ” for f to P 2 along with keys for its own input • P 2 obtains the keys for its input using oblivious transfer • P 2 evaluates the garbled circuit This gives semi-honest security only!

General feeling (~2000): Hopelessly imprac@cal

Efficiency (semi-honest) AES 25 20 15 @me (log scale) 10 0.5 ms 5 0 Fairplay PSSW09 TaSTY HEKM11 LR15

Efficiency (malicious) AES, 40-bit sta9s9cal security 25 20 15 @me (log scale) 10 65 ms 5 0 PSSW09 SS11 AMPR14 LR15 WMK16

Efficiency 25 20 15 Semi-honest 10 Malicious 5 0 2004 2009 2011 2015/6

Real-world interest • Par9sia (3-party) – Danish sugar-beet auc@on (2008-present(?)) – Wireless-spectrum auc@ons • Sharemind (3-party) – Sta@s@cal analysis of financial data • Sepior, Dyadic (2-party) – AES • IARPA SPAR, DARPA PROCEED/Brandeis

Research ques9ons • “Cryptographic” – Mul@-party sehng • Protocols, “real-world” issues – Post-quantum security – Alternate models of computa@on – Composability – What func@ons are “safe” to compute?

Research ques9ons • “Non-cryptographic” – Usability – PL/compiler support – Formal verifica@on of protocols, implementa@ons

Real-world ques9ons • Will secure computa@on be of niche interest, or will it be more widespread ? • What is the business model ? • What security requirements suffice? • What are the right cost metrics ? • What is the barrier to more widespread use of secure computa@on?

Real-world ques9ons • Will there be mul9ple applica@ons of secure computa@on, or just a few ? – Should we focus on generic systems, or op@mize for specific “killer applica@ons”? – What are the “killer applica@ons”? • Who will be wri@ng code? – Where should we focus our a8en@on when wri@ng compilers ?

Conclusions • Tremendous advances in past few years • Greater deployment in the near future(?)

Acknowledgments Research supported by – NSF (“TC: Large: Collabora@ve Research: Prac@cal Secure Computa@on: Techniques, Tools, and Applica@ons”) – US ARL/UK MoD (“Secure Informa@on Flows in Hybrid Coali@on Networks”) – DARPA (“Toward Prac@cal Cryptographic Protocols for Secure Informa@on Sharing”)

Thank you! Papers and code available from h,p://www.cs.umd.edu/~jkatz/papers.html