P4P: A Framework for Practical Server-Assisted Multiparty Computation with Privacy

1
P4P A Framework for Practical Server-Assisted
Multiparty Computation with Privacy

• Yitao Duan
• Berkeley Institute of Design
• UC Berkeley
• Qualifying Exam
• April 18, 2005

2
Outline

• Problem and motivation
• Privacy issues examined
• Privacy is never a purely tech issue
• Derive some design principles
• The P4P framework
• Applications
• Practical multiparty arithmetic computation with
  privacy
• Service provision with privacy
• Progress and future work

3
Problem Scenario
4
Applications and Motivation

• Next generation search makes heavy use of
  personal data for customized search,
  context-awareness, expertise mining and
  collaborative filtering
• E-commerce vendors (like Amazon) try to build
  user purchase profiles across markets. And user
  profiling is moving onto the desktop
• Location based services, real-world monitoring

5
Outline

• Problem and motivation
• Privacy issues examined
• Privacy is never a purely tech issue
• Derive some design principles
• The P4P framework
• Applications
• Practical multiparty arithmetic computation with
  privacy
• Service provision with privacy
• Progress and future work

6
Legal Perspectives

• Privacy issues arise as a tension between two
  parties one seeks info about the other
• Identity of the seeker leads to different
  situations and precedents
• E.g. individual vs, the press, vs. the employer
• Power imbalance between the two
• Loss of privacy often leads to real harm e.g.
  loss of job, loss of right, etc.

AK95
7
Economic Perspectives

• Market forces work against customer privacy
• Company has to do extra work to get less info
• Company can benefit from having user info
• So they lack the incentive to adopt PETs
• Power imbalance (again!) in e-commerce
• But we, as users, can make a difference by
  flexing our collective muscles!
• Users often underestimate the risk of privacy
  intrusion and are unwilling to pay for PET

FFSS02,ODL02, A04
8
Social Science Perspectives

• Privacy is NOT minimizing disclosure
• Maintaining a degree of privacy often requires
  disclosure of personal information Altman 75
• E.g. faculty members put Perspective students
  please read this before you email me on their
  web page
• Sociality requires free exchange of some
  information
• PET should not prevent normal exchange

9
Lessons for Designing Practical Systems

• Almost all problems are preserved, or even
  exaggerated in computing
• Tension exists but court arbitration not
  available
• Power imbalance prevails with no protection of
  the weak client/server paradigm
• Lack of incentive (to adopt PET, to cooperate,
  etc)
• Design constraints for practical PET
• Cost of privacy must be close to 0. And the
  privacy scheme must not conflict with the
  powerful actors need

10
Outline

• Problem and motivation
• Privacy issues examined
• Privacy is never a purely tech issue
• Derive some design principles
• The P4P framework
• Applications
• Practical multiparty arithmetic computation with
  privacy
• Service provision with privacy
• Progress and future work

11
The P4P Philosophy
You cant wait for privacy to be granted. One has
to fight for it.
12
P4P ?2 Principles

• Prevention Not deterrence
• Incentive Design should consider the incentives
  of the participants
• Protection Design should incorporate mechanisms
  that protect the weak parties
• Independence The protection should be effective
  even if some parties do not cooperate

13
Topologies
S
P2P
Client-server
14
Problems With the Two Paradigms

• Client-server
• Power imbalance
• Lack of incentive
• P2P
• Doesnt always match all the transactions models
  (e.g. buying PCs from Dell)
• Hides the heterogeneity
• Many efficient server-based computation are too
  expensive if done P2P

15
The P4P Architecture
Privacy Peer (PP)

• A subset of users are elected as privacy
• providers (called privacy peers) within the
  group
• PPs provide privacy when they are available, but
• cant access data themselves

16
P4P Basics

• Server is (almost) always available but PPs
  arent (but should be periodically)
  asynchronous or semi-synchronous protocols
• Server provides data archival, and synchronizes
  the protocol
• Server only communicates with PPs occasionally
  (when they are online and light-loaded eg 2AM)

• Server can often be trusted not to bias the
  computation but we have means to verify it
• PPs and all other user are completed untrusted

17
The Half-Full/Half-Empty Glass
In a typical P2P system, 5 of the peers provide
70 of the services GFS

• P2P 70 of the users are free riding

• P4P 5 of the users are serving the community

Enough for P4P to work practically!
18
Roles of the Privacy Peers

• Anonymizing Communication
• E.g. Anonymizer.com or Mix
• Offloading the Server
• Sharing Information
• Participating in Computation
• Others Infrastructure Support

19
Tools and Services

• Cryptographic tools Commitment, VSS, ZKP,
  Anonymous authentication, eCash, etc
• Anonymous Message Routing
• E.g. MIX network CHAUM
• Data protection scheme PET04
• ? the set of users whom should have access to X
• Anonymous SSL

20
Practical Multiparty Arithmetic Computation with
Privacy
Applications
21
Multiparty Computation
Applications

• n parties with private inputs wish to compute
  some joint function of their inputs
• Must preserve security properties. E.g., privacy
  and correctness
• Adversary participants or external
• Semi-honest follows the protocol but curious
• Malicious can behave arbitrarily

22
MPC Known Results
Applications

• Computational Setting Trapdoor permutations
• Any two-party function can be securely computed
  in the semi-honest model Yao
• Any multiparty function can be securely computed
  in the malicious model, for any number of
  corrupted parties GMW
• Info-Theoretic Setting No complexity assumption
• Any multiparty function can be securely computed
  in the malicious model if 2/3n honest parties
  BGW,CCD
• With broadcast channel, only gt1/2n honest
  partiesRB

23
A Solved Problem?
Applications

• Boolean circuit based protocols totally
  impractical
• Arithmetic better but still expensive the best
  protocols have O(n3) complexity to deal with
  active adversary
• Cant be used directly in real systems with large
  scale 103 106 users each with 103 106 data
  items

24
Contributions to Practical MPC
Applications

• P4P provides a setting where generic arithmetic
  MPC protocols can be run much more efficiently
• Existing protocols (the best one) O(n3)
  complexity (malicious model)
• P4P allows to reduce n without sacrificing
  security
• Enables new protocols to make a whole class of
  computation practical

25
Arithmetic Homomorphism vs VSS
Applications

• Homomorphism E(a)E(b) E(ab)
• Verifiable Secret Sharing (VSS) a ?a1, a2, an
• Addition easy
• E(a)E(b) E(ab)
• share(a) share(b) share(ab)
• Multiplication more involved for both
• HOMO-MPC O(n3) w/ big constant CDN01, DN03
• VSS-MPC O(n4) (e.g. GRR98)

26
Arithmetic Homomorphism vs VSS
Applications

• HOMO-MPC
• Can tolerate t lt n corrupted players as far as
  privacy is concerned
• Use public key crypto, 10,000x more expensive
  than normal arithmetic (even for addition)
• Requires large fields (e.g. 1024 bit)
• VSS-MPC
• Addition is essentially free
• Can use any size field
• - Cant tolerate t gt n/2 corrupted players (cant
  do two party multiplication)

27
Bridging the Two Paradigms
Applications

• HOMO-MPC ? VSS-MPC
• Inputs c E(a) (public)
• Outputs sharei(a) DSKi(c) (private)
• VSS-MPC ? HOMO-MPC
• Inputs sharei(a) (private)
• Outputs c ? E(sharei(a)) (public)
• A hybrid protocol possible

28
Efficiency Security Assumptions
Applications

• Existing protocols uniform trust assumption
• All players are corrupted with the same
  probability
• Damages caused by one corrupted player another
• A common mechanism to protect the weakest link
  against the most severe attacks
• But players are heterogeneous in their
  trustworthiness, interests, and incentives etc.
• Cooperation servers behind firewalls
• Desktops maintained by high school kids
• The collusion example

29
Exploiting the Difference
Applications

• Server is secure against outside attacks
• Companies spend to protect their servers
• The server often holds much more valuable info
  than what the protocol reveals
• PPs wont collude with the server
• Interests conflicts, mutual distrust, laws
• Server cant trust clients can keep conspiracy
  secret
• Server wont corrupt client machines
• Market force and laws
• Rely on server for protection against outside
  attacks, PPs for defending against a curious
  server

30
How to Compute Any Arithmetic Function P4P Style
Applications

• Each player secret shares her data among the
  server and one PP using (2, 2)-VSS
• Server and PP convert to a HOMO-MPC for mult. Use
  VSS for addition. Result obtained by threshold
  decryption or secret reconstruction
• Dealing with malicious adversary cheating PP
  replaced by another
• 2 ltlt n!
• Communication independent of n
• Computation on talliers fully distributed
  version

31
Addition Only Algorithms
Applications

• Although general computation made more efficient
  in P4P, multiplication still way more expensive
  than addition
• A large number of practical algorithms can be
  implemented with addition only aggregation
• Collaborative filtering IEEESP02, SIGIR02
• HITS, PageRank
• E-M algorithm, HMM, most linear algebra
  algorithms

32
New Vector Addition Based MPC
Applications

• User i has an m-dimensional vector di, want to
  compute
• y, A F(Si1n di, A)
• Goals
• Privacy no one learns di except user i
• Correctness computation should be verified
• Validity di2 lt L w.h.p.

33
Cost for Private Computation Vector Addition Only
Applications
Cost for privacy/security
Total computation cost
Cost for computation on obfuscated data
sCO(mn) for both HOMO and VSS
34
Cost for Private Computation Vector Addition Only
Applications
Cost for privacy/security
Total computation cost
O(nlogm)
Cost for computation on obfuscated data
The hidden const HOMO 10,000 VSS 1 or 2
sCO(mn) for both HOMO and VSS
35
Basic Architecture
Applications
ui
vi
ui vi di
36
Basic Architecture
Applications
µ Sui
? Svi
ui vi di
37
Basic Architecture
Applications
µ
?
µ Sui
? Svi
ui vi di
38
Basic Architecture
Applications
y, A F(µ ?, A)
39
Adversary Models
Applications

• Model 1 Any number of users can be corrupted by
  a malicious adversary Both PP and the server can
  be corrupted by different semi-honest adversary
• Model 2 Any number of users and the PP can be
  corrupted by a malicious adversary. The server
  can be corrupted by another malicious adversary
  who should not stop

40
An Efficient Proof of Honesty
Applications

• Show that some random projections of the users
  vector are small
• If user fails T out of the N tests, reject his
  data
• One proof/user vector and complexity O(logm)

41
Success Probability
Applications
42
Complexity and Cost
Applications

• Only one proof for each user vector no
  per-element proofs!
• Computation ? size of sk O(log m)
• m 106, ? l 20, with N 50, need 1420
  exponentiations
• 5s/user

Benchmark http//botan.randombit.net/bmarks.html,
1.6 Ghz AMD Opteron (Linux, gcc 3.2.2)
43
Service Provision with Privacy
Applications
44
Existing Service Architecture
Applications
45
Traditional Service Model
Applications

• Requires or reveals private user info
• Locations, IP addresses, the data downloaded
• Requires user authentication
• Subscription verification and billing purposes
• Traditional client-server paradigm allows the
  server to link these two pieces of info
• P4P keeps them separate

46
P4Ps Service Model
Applications

• Authenticates user
• Anonymizes comm.

• Processes the
• transaction

• PP knows users identity but not his data
• Server knows users transaction but not his ID
• To the PP Transactions protected w/ crypto
• To the server Transactions unlinkable to each
• other or to a particular user

47
Possible Issues
Applications

• The scheme involves multiple parties, why would
  they cooperate?
• Servers concerns and fears Privacy peers are
  assigned the task of user authentication, how
  could the server trust the privacy peers?
• Can the server block the PPs?
• How to motivate the privacy peers?
• How do we detect and trace any fraud?

48
Solutions
Applications

• Mechanism to detect fraud and trace faulty
  players
• PP incentive Rely on altruism or mechanism to
  credit the PPs
• (An extreme) A fully P2P structure among the
  users and PPs
• Server cannot isolate the PPs
• Independence!
• A partial P2P structure should work (e.g.5PP)

49
Billing Resolution
Applications

• Fraud detection together with bill resolution
• Have schemes for a number of billing models
  (flat-rate, pay-per-use)
• No info about users transactions (except those
  of the faulty players) is leaked
• An extension PP replaced by a commercial privacy
  provider who does it for a profit
• Now you can use its service and dont have to be
  embarrassed by Amazon knowing the DVD title you
  buy
• http//www.cs.berkeley.edu/duan/research/qual/sub
  mitted/trustbus05.pdf

50
Conclusions

• System design guidelines drawn from legal,
  economic and social science research
• P4P argues for peer involvement and exploits the
  heterogeneity among the players and provides a
  viable framework for practical collaborative
  computation with privacy
• P4P allows for private computation based on VSS
  privacy offered in P4P almost for free!

51
Progress So Far

• Published work
• Data protection PET04
• Link analysis SIAM Link Analysis Workshop
• Submitted
• Group Communication Cryptosystem
• Service Provision with Privacy
• In progress
• Practical Vector Addition Based Computation
• Hybrid MPC
• Anonymous SSL

52
Plan and Future Work

• Finish the work at hand
• Extend the practical computation to support
  multiplication?
• Hybrid Homomorphism and VSS based scheme
• VSS Efficient multiplication possible if we can
  have 3 non-colluding players (another server?
  Another PP?)
• More applications?
• Implementation
• A P4P toolkit or lib that developers can use to
  built their application
• Time to graduate 12 to 18 months

53
References

• AK95 Alderman, E., Kennedy, C. The Right to
  Privacy. DIANE Publishing Co. (1995)
• Altman75 Altman, E. The Environment and Social
  Behavior. Brooks/Cole Pub. Co. (1975)
• DC04 Duan, Y., Canny, J. Protecting user data
  in ubiquitous computing Towards trustworthy
  environments. In PET04. PK01 Pfitzmann, A.,
  Kohntopp, M. Anonymity, unobservability, and
  pseudonymity A proposal for terminology. Draft,
  ver0.17 (2001)
• Yao Yao, A.C.C. Protocols for secure
  computations. In FOCS '82
• GMW Goldreich, O., Micali, S., Wigderson, A.
  How to play any mental game - a completeness
  theorem for protocols with honest majority. In
  STOC87
• CDN01 R. Cramer et. al Multiparty Computation
  from Threshold Homomorphic Encryption, EUROCRYPT
  '01
• GFS E. Adar and B. Huberman, Free Riding on
  Gnutella
• A04 Acquisti, A. Privacy in electronic
  commerce and the economics of immediate
  gratication. In ACMEC '04

54
References

• GRR98 R. Gennaro et. AlSimplified VSS and
  fast-track multiparty computations with
  applications to threshold cryptography, PODC '98
• DN03 I. Damgård and J. Nielsen Universally
  Composable Efficient Multiparty Computation from
  Threshold Homomorphic Encryption, CRYPTO 2003
• BGW Ben-Or, M., Goldwasser, S., Wigderson, A.
  Completeness theorems for non-cryptographic
  fault-tolerant distributed computation. In
  STOC'88
• CCD Chaum, D., Crepeau, C., Damgård, I.
  Multiparty unconditionally secure protocols. In
  STOC 88
• RB Rabin, T., Ben-Or, M. Verifiable secret
  sharing and multiparty protocols with honest
  majority. In STOC '89
• CD98 Cramer, R., Damgård, I. Zero-knowledge
  proof for finite field arithmetic, or Can
  zero-knowledge be for free? In CRYPTO '98

55
Thank You!
56
Protecting the Transactions
Applications
PP Verifies cert, hash signature
P
M
A
S
Q0 The query, hQ h(Q)
57
Protecting the Transactions
Applications
S Verifies cert, hash signature

• PP performs authentication, S processes query
• PP knows users identity but not his data
• S knows users transaction but not his ID

58
An Efficient Proof of Honesty
Applications
ck
Randomly selects ck from -1, 1m, k 1, 2, , N
ck
ui vi di
59
An Efficient Proof of Honesty
Applications
(xk, ?k, Xk)
(yk, ?k, Yk)
60
An Efficient Proof of Honesty
Applications
61
An Efficient Proof of Honesty
Applications
Xk, Yk
Z XkYk
62
An Efficient Proof of Honesty
Applications
Z XkYk
Zj, j 1, , l
Zj, j 1, , l
63
An Efficient Proof of Honesty
Applications
Z ?Zj?
64
An Efficient Proof of Honesty
Applications
Z ?Zj
ZKP Zj, contains a bit (i.e. 0 or 1)
ZKP Zj, contains a bit (i.e. 0 or 1)
Using the bit commitment proof of CD98
65
Effectiveness

• ckj is selected from -1, 1, a zero-mean, unit
  variance random variable
• sk ckTdi, also a zero-mean R.V.
• VAR(sk) di2
• The protocol bounds its var by bounding the RV
• Optimal results by tuning T and N

66
Optimizations

• Vector commitment and proof of bit vector
  commitment reduce the computation by half and
  communication for commitment by N
• User is allowed to acknowledge up to T failed
  tests
• Disqualify a user on the first failed test she
  claims to pass
• Only need to actually run at most N T tests
  (30 more efficient)

67
Privacy Goals PK01

• Unobservability The state of IOIs (Items of
  Interest) being indistinguishable from any IOIs
  at all
• Unlinkability IOIs are no more and no less
  related than they are not related
• Anonymity The state of being not identifiable
  within a set of subjects, the anonymity set
• Pseudonymity Using a pseudonym as ID

68
P4P Architecture

• A subset of users are elected as privacy
• providers (called privacy peers) within the
  group
• PPs provide privacy when they are available, but
• cant access data themselves

69
The P4P Architecture
70
Billing Resolution Example Flat Rate Model
Applications

• Server charges a flat fee for the service
• But place a limit on the maximum resource a user
  can consume
• User pays directly to server no PayPal
• Goals
• Server is guaranteed to obtains fair payment for
  the services it provides
• Fraud detection
• No leaking of info about transactions

71
Basic Tools Homomorphic Commitment
Applications
Commit
A C(a, r)
a
72
Basic Tools Homomorphic Commitment
Applications
Open
a, r
a
A C(a, r)?
Homomorphism C(a1, r1) C(a2, r2) C(a1a2,
r1r2)
73
Billing Resolution Example Flat Rate Model
Applications
cA C(sA, rA)
(sA, rA)
sA Resource used (e.g. of trans.) C
Homomorphic commitment rA Randomness
74
Billing Resolution Example Flat Rate Model
Applications
A is a legitimate customer?
ZKP sA, lt L
Using the protocol to be explained later
75
Billing Resolution Example Flat Rate Model
Applications
cA C(sA, rA)? Is sA consistent with my record?
Servers signature on cA
76
Billing Resolution Example Flat Rate Model
Applications
(r, U)
UThe set of users who failed to submit a valid
receipt
s Total number of trans.
77
Billing Resolution Example Flat Rate Model
Dont show this!
Applications
sQ