SPAR-MPC Day 1 Breakout Sessions Emily Shen 29 May 2014

Day 1 Breakout Sessions-2 ES 5/29/2014 A High-Level SPAR-MPC Architecture Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements

Day 1 Breakout Sessions-3 ES 5/29/2014 A High-Level SPAR-MPC Architecture Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements Some developer and cryptographer tasks may be automatable

Day 1 Breakout Sessions-4 ES 5/29/2014 User Input Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements User describes: –Who are the participants in the protocol? –What needs to be shared, and what needs to be kept private Likely answers: –“I want X to remain secret” –“I will go 10x faster if you betray only a little information” –“Keep X secret from A; Y secret from B” –“I’m ok with you revealing a set of possible results but not a specific” –“I’m ok with revealing the size of the result” –“After a week, then the data can be leaked”

Day 1 Breakout Sessions-5 ES 5/29/2014 Motivating Use Cases Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements Queries on phone call metadata –Parties: caller, callees, phone company (storage), Gov’t (querier) –Permit: Query for all records up to two “hops” from suspect # –Protect suspect and result #s from phone company, other phone numbers from govt Query for average income of students at a US school –Parties: students, schools, Dept. of Ed (storage), analyst (querier) –Permit: Aggregate statistical queries, e.g., average income of grads –Protect SSNs, individual salaries from analyst, Dept. of Ed

Day 1 Breakout Sessions-6 ES 5/29/2014 Motivating Use Cases Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements Outsourced computation in the cloud Social benchmarking Health care information sharing, monitoring Mobile sensor data analysis

Day 1 Breakout Sessions-7 ES 5/29/2014 User Specification of Leakage Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements Obvious leakage measures (e.g., bits) are nearly impossible to ask a user –Hard for user to specify –Hard to understand semantic meaning –Leakage implications changes over time e.g., genetic information Leakage expressed as alternatives in trust and efficiency might be usable, enumerable –Two party, slower protocol –Trusted third party, faster protocol

Day 1 Breakout Sessions-8 ES 5/29/2014 Translation Between Application Requirements and Crypto Requirements Four types of communication –User → Cryptographer: conveying security requirements –Cryptographer → cryptographer: describing a protocol –Cryptographer → developer: explaining what to implement –Cryptographer → end user: articulating privacy guarantees achieved All of these communications are important But, there can be an impedance mismatch at each one

Day 1 Breakout Sessions-9 ES 5/29/2014 User → Cryptographer Conveying security requirements Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements User challenges Need list of options to choose from Don’t understand requirements Can’t convey them Cryptographer challenges Capturing reqs Converting informal reqs into formal ones Interdisciplinary problem Legal/policy NLP Usability

Day 1 Breakout Sessions-10 ES 5/29/2014 Cryptographer → Cryptographer Describing a protocol’s security guarantees Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements Leakage inherently incomparable in general Semantic vs. number of bits leaked Depends on details of protocols Leakage hierarchy for specific domains may be feasible Access patterns to data structures Non-interactive primitives: deterministic encryption, OPE, FE, … Don’t want to rule out good ideas by restricting leakage language Leakage driven by desired performance

Day 1 Breakout Sessions-11 ES 5/29/2014 Cryptographer → Cryptographer Describing a protocol’s security guarantees Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements Real / ideal model lets you specify leakage, but does not give ways to compare Compare based on what must not leak instead –What can adversary learn from leakage? –Quantitative Information flow –Statistical inference –Caveat: No good lower bounds on learning Differential privacy-style approach –What prior knowledge would adversary need to learn the specific sensitive data?

Day 1 Breakout Sessions-12 ES 5/29/2014 Cryptographer → Cryptographer Describing a protocol’s security guarantees Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements We should have examples for why a given leakage is bad If can’t find an example, it might be okay (e.g., Tor) Describe relative tradeoffs of leakage choices, not just absolute leakage Value of proofs? Challenging to absorb Tedious to verify/understand Statistical modeling can provide a measure of “goodness” for privacy

Day 1 Breakout Sessions-13 ES 5/29/2014 Cryptographer → Developer Explaining what to implement Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements Coders good at designing + implementing, need help with security Standardized language from the crypto community would help developers know what to implement

Day 1 Breakout Sessions-14 ES 5/29/2014 Cryptographer → End User Articulating privacy guarantees achieved Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements Two security notions to convey at once How data is hidden (example: encryption) How an interactive protocol constantly protects privacy against attack (this is harder) Public grasps security better than experts think Must explain nuances of security tradeoffs Balance: can’t show too much or too little Must disabuse end user of notion that “computer knows sensitive data, just not showing it to me”

Day 1 Breakout Sessions-15 ES 5/29/2014 Cryptographer → End User Explaining real-world impact of leakage Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements Impact depends on application, users’ goals, attackers’ goals Compare quality of adversary models through attacker impact –HBC/covert/local/access patterns/equality –Requires a system to be of interest to attackers –Needs to be done without allowing real privacy breaches Arguing that leakage is not an attack is tricky: –Difficult to argue what can/cannot be learned from leakage –Sensitivity of information changes over time –Want research on “cryptanalysis” of privacy

Day 1 Breakout Sessions-16 ES 5/29/2014 Cryptographer → End User Understanding Leakage vs. Damage Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements Leakage: Learnable information given transcript Can be chained/combined with auxiliary information to gain additional leakage Application/stakeholder independent Damage Information considered harmful Damage can be compared with benefit of running application Application/stakeholder dependent Create database of known attacks/ways of combining leakage Counter-balances toolchain of known MPC protocols Using attack trees to chain together leakage User knowledge needed to say what constitutes damage

Day 1 Breakout Sessions-17 ES 5/29/2014 Cryptographer → End User Understanding Leakage vs. Damage Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements Leakage and corresponding damage evolve over time Complexity-based crypto is uncomfortable with patch/fix cycle –We think of privacy breaches as forever Symmetric cryptography dealt with this cycle for years –Understanding and preventing known attacks –Current ciphers/hashes are believed to be quite strong

Day 1 Breakout Sessions-18 ES 5/29/2014 A High-Level SPAR-MPC Architecture Implementations Proofs End User Cryptographer Developer Tool 1 Tool 2 What to compute, what to protect and prevent Leakage, adversary model Design Implications Tradeoffs Requirements

Day 1 Breakout Sessions-19 ES 5/29/2014 Structure of MPC Tool First, want a library of MPC tools, mechanism for choosing proper building blocks –Could we build a new library subsuming existing libraries? Then, want a compiler that takes specification, selects proper protocols, produces implementations General consensus –common API for all performers and tools will be challenging, though some interoperability may be encouraged Program specification should be written in a language that is amenable to analysis, e.g., FairPlay

Day 1 Breakout Sessions-20 ES 5/29/2014 Layers of MPC Tools Analogy: network stack model Basic tools –Garbled Circuits –OT extensions –ORAM –Linear secret sharing Common operations –Sorting –Comparisons Higher Level Techniques –2 PC vs. 3 PC –Preprocessing

Day 1 Breakout Sessions-21 ES 5/29/2014 Composability Components should come with specifications of functionality and security Need a composition framework –Especially for components with imperfect security –Might be worth considering more realistic adversary models –Given different situations, there are different applicable proofs Limited composability may be possible –Not full interoperability