SLIDE 1
Be,er Privacy and Security via Secure Computa9on Jonathan Katz - - PowerPoint PPT Presentation
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
SLIDE 2
SLIDE 3
…if there were someone we could all TRUST with our data
SLIDE 4
Be8er data mining -- using MORE data, while respec@ng users’ PRIVACY
SLIDE 5
SLIDE 6
SLIDE 7
CONTROLLED informa@on sharing
SLIDE 8
SLIDE 9
SLIDE 10
Be8er privacy/security for EVERYONE
SLIDE 11
SLIDE 12
SLIDE 13
SLIDE 14
Would be nice if there were someone we could all TRUST with our data…
SLIDE 15
But there isn’t
SLIDE 16
- Legal/regulatory restric@ons
- Not economically viable (cost +
liability vs. value)
- Central point of failure/a8ack
- Incompa9ble trust frameworks
SLIDE 17
Would be nice if there were someone we could all TRUST with our data… Would be even be,er if we could AVOID the need for trust in the first place!
SLIDE 18
SLIDE 19
SLIDE 20
Secure computa9on ensures:
- Confiden9ality
– No party’s input is revealed
- Integrity
– Correct output is computed
- Availability
– All par@es obtain the output
- Input independence
– Each party’s input is independent of the others’
Caveats
SLIDE 21
Assump9ons/caveats
- Number of malicious par@es (some@mes)
- Ac9ons of malicious par@es (some@mes)
- Cryptographic hardness (some@mes)
- Weaker guarantees (some@mes)
SLIDE 22
Secure computa@on of any func@on, with security against arbitrary behavior
- f any number of par@es, is possible
SLIDE 23
Two-party seRng
- Start with a boolean circuit for f
- P1 sends a “garbled circuit” for f to P2
along with keys for its own input
- P2 obtains the keys for its input using
- blivious transfer
- P2 evaluates the garbled circuit
This gives semi-honest security only!
SLIDE 24
General feeling (~2000):
Hopelessly imprac@cal
SLIDE 25
Efficiency (semi-honest)
5 10 15 20 25 Fairplay PSSW09 TaSTY HEKM11 LR15
AES
@me (log scale)
0.5 ms
SLIDE 26
Efficiency (malicious)
5 10 15 20 25 PSSW09 SS11 AMPR14 LR15 WMK16
AES, 40-bit sta9s9cal security
@me (log scale)
65 ms
SLIDE 27
Efficiency
5 10 15 20 25 2004 2009 2011 2015/6
Semi-honest Malicious
SLIDE 28
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
SLIDE 29
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?
SLIDE 30
Research ques9ons
- “Non-cryptographic”
– Usability – PL/compiler support – Formal verifica@on of protocols, implementa@ons
SLIDE 31
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?
SLIDE 32
Real-world ques9ons
- Will there be mul9ple applica@ons of
secure computa@on, or just a few?
– Should we focus on generic systems, or
- p@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?
SLIDE 33
Conclusions
- Tremendous advances in past few years
- Greater deployment in the near
future(?)
SLIDE 34
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”)
SLIDE 35