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

SPAR-MPC Day 1Breakout Sessions

Emily Shen29 May 2014

Day 1 Breakout Sessions-2ES 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 modelDesign

Implications

Tradeoffs

Requirements




End User

Cryptographer

Developer

Tool 1

Tool 2


and prevent


Implications

Tradeoffs

Requirements

• Some developer and cryptographer tasks may be automatable


User Input


End User

Cryptographer

Developer

Tool 1

Tool 2


and prevent


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”


Motivating Use Cases


End User

Cryptographer

Developer

Tool 1

Tool 2


and prevent


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


Motivating Use Cases


End User

Cryptographer

Developer

Tool 1

Tool 2


and prevent


Implications

Tradeoffs

Requirements• Outsourced computation in the cloud

• Social benchmarking

• Health care information sharing, monitoring

• Mobile sensor data analysis


User Specification of Leakage


End User

Cryptographer

Developer

Tool 1

Tool 2


and prevent


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


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


User → CryptographerConveying security requirements


End User

Cryptographer

Developer

Tool 1

Tool 2


and prevent


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


Cryptographer → CryptographerDescribing a protocol’s security guarantees


End User

Cryptographer

Developer

Tool 1

Tool 2


and prevent


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




End User

Cryptographer

Developer

Tool 1

Tool 2


and prevent


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?




End User

Cryptographer

Developer

Tool 1

Tool 2


and prevent


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


Cryptographer → DeveloperExplaining what to implement


End User

Cryptographer

Developer

Tool 1

Tool 2


and prevent


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


Cryptographer → End UserArticulating privacy guarantees achieved


End User

Cryptographer

Developer

Tool 1

Tool 2


and prevent


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”


Cryptographer → End UserExplaining real-world impact of leakage


End User

Cryptographer

Developer

Tool 1

Tool 2


and prevent


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


Cryptographer → End UserUnderstanding Leakage vs. Damage


End User

Cryptographer

Developer

Tool 1

Tool 2


and prevent


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


Cryptographer → End UserUnderstanding Leakage vs. Damage


End User

Cryptographer

Developer

Tool 1

Tool 2


and prevent


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




End User

Cryptographer

Developer

Tool 1

Tool 2


and prevent


Implications

Tradeoffs

Requirements


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


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


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

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

Documents

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