1 / 36

Reputation Systems for Anonymous Networks

Reputation Systems for Anonymous Networks. Seung Geol Choi Columbia University. joint work with. Elli Androulaki, Steven M. Bellovin, Tal Malkin Columbia University. Contents. Introduction Security Model Our Construction Future Directions. Introduction. P2P in Anonymous networks - 1.

justus
Download Presentation

Reputation Systems for Anonymous Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Reputation Systemsfor Anonymous Networks Seung Geol Choi Columbia University joint work with Elli Androulaki, Steven M. Bellovin, Tal Malkin Columbia University

  2. Contents • Introduction • Security Model • Our Construction • Future Directions

  3. Introduction

  4. P2P in Anonymous networks - 1 • P2P in Anonymous networks • Underlying network is anonymous (eg. Mixnet, Onion Router) • Each peer represents himself via a pseudonym • Real identity need not be revealed in transactions

  5. P2P in Anonymous networks - 2 • Total anonymity is problematic • Misbehaviors are untraceable: peers can easily change their pseudonyms arbitrarily. Misbehaviors remain unpunished Honest peers suffer from misbehaviors • One reasonable solution: reputation system

  6. Reputation system • After a transaction, pseudonym P gives a reputation point to pseudonym Q. • Reputation value of P: total rep-points P has gained. • Reputation values are easily accessible. • Based on the reputation, peers can decide whether to execute a transaction with that peer. • Reputation values should be bound to each peer (identity) not pseudonym.

  7. Identity-Bound Reputation • Why identity-bound? • Malicious peer are willing to change his pseudonym to a new one  reputation system doesn’t serve its purpose. • Honest peer are reluctant to change his pseudonym  Anonymity is not enjoyed by him. • To achieve it, we need a trusted party to manage reputations correctly.

  8. Honest vs. Honest-but-curious • In existing systems [V04, S06], the trusted party is assumed totally-honest. • It knows who gives a reputation point to whom, but is assumed to keep the information secret. • But, better assume it is honest-but-curious • We can not make sure that it doesn’t leak the traffic information; anonymity may be compromised. • Need a system that remains anonymous even to the trusted party.

  9. Our Contribution • Propose identity-bound reputation system in P2P pseudonymous networks • Definition of Security • Anonymity holds even if the bank is trying to break it. • Construction

  10. Security Model

  11. Participating Entities • Peers • Regular users of a P2P network • Buyers and/or Merchants • Each peer has one or more pseudonyms • Bank • Manages reputation database wrt each peer • Honest-but-curious Correctly updates reputation info. may try to break unlinkability (discussed later)

  12. Operations - 1 • Key Generation Algorithms • Bank: Bkeygen() • Peer’s Identity: Ukeygen() • Peer’s Pseudonym: Pnymgen()

  13. Operations - 2 • RepCoin Related Operations • repcoins  RepCoinWithdraw(U) : peer U withdraws repcoins from the Bank • Award(P[repcoin], Q): pseudonym P of U gives a repcoin to pseudonym Q of M • RepCoinDeposit(M, repcoin): received repcoin is deposited into M’s account in the Bank.

  14. Reputation granting process Bank RepCoinWithdraw RepCoinDeposit U M P Q Award

  15. Operations - 3 • Administrative Operations • proof  Identify(repcoin): the Bank checks if the repcoin is double-spent. • VerifyGuilt(proof, repcoin): verify that the proof is correct

  16. Operations - 4 • Reputation Showing • credential  RepCredRequest(U): peer U obtains a credential according to its reputation • ShowReputation(P, credential): shows that pseudonym P has a certain reputation

  17. Reputation showing process Bank RepCredRequest U M P Q ShowReputation

  18. Security

  19. Correctness • Correct reputation granting process • If the process happens between honest bank and honest peers U and M, M’s reputation is increased by one. • Correct reputation showing process • If the process happens between honest bank and honest peers U and M, M can prove his reputation using RepCredRequest() and ShowReputation().

  20. No Over-Awarding • No Collection of peers can award more repcoins than they withdrew. • If the same repcoin is used twice in awarding, the bank can find out who did it using Identify()/VerifyGuilt(). • We allow that the received repcoin may increase another peer’s reputation. • M can give the repcoin to M’ (collusion). Then M’ can use the repcoin in increasing its reputation. But, then the reputation of M is not increased.

  21. Exculpability • Honest peer is protected from framing. • No coalition of peers, even with the Bank, can forge a proof such that Verifyguilt(proof, repcoin) is true.

  22. Reputation Unforgeability • No coalition of peers can show a reputation which is greater than the highest of any of them. • A single peer cannot forge his reputation (special case) • If a peer U, by colluding with M, could show a reputation higher than its original one, then U must learn M’s master secret key.

  23. Peer-Pseudonym Unlinkability • Peers consistent-looking with pseudonym P : all the peers that have more reputation than what P showed in reputation showing procedure. • Peer-Pseudonym Unlinkability • Given an honest pseudonym P, the adversary, colluding peers including Bank, guesses the owner of P no better than randomly guessing among the peers consistent-looking with P

  24. Pseudonym-Pseudonym Unlinkability • Given two honest pseudonyms P and Q, the adversary, colluding peers including Bank, has no advantage in guessing whether P and Q belong to the same user as long as there are at least two honest peers consistent-looking with both P and Q.

  25. Our Construction

  26. Basic Approach - 1 • Reputation granting • Use e-cash as repcoin: provides anonymity for e-cash spenders. • Reputation showing • Use anonymous-credential system: provides anonymity for credential-holders.

  27. Basic Approach - 2 • Reputation level • In reputation showing procedure, reputation is shown by the level. E.g. level x: the peer has more than 2x reputation points. • Showing exact reputation may compromise pseudonym-pseudonym unlinkability.

  28. Reputation granting process Bank (S, pi) EC.Withdraw() EC.Deposit() W (S, pi) U M P Q EC.Spend()

  29. Reputation showing process Bank AC.GrantCred() cred U M P Q AC.VerifyCred()

  30. Caveat • The problem lies in achieving unlinkability • E-cash is not enough • only provides privacy on the awarding side.

  31. Caveat: Reputation granting process Bank (S, pi) EC.Withdraw() EC.Deposit() W (S, pi) U M P Q EC.Spend() If Bank and U collude, they will know Q belongs to M

  32. Idea • Introduce another level of blinding • Blind Permission: basically a blind signature. • Now, Q submits (S, pi) to the Bank. • Bank generates a blind signature and gives it to Q. • Then M submits the unblinded form of the signature to the Bank • Bank increases M’s reputation value.

  33. Reputation granting process Bank sig BS.Sign() (S, pi) C W BS.Verify() (S, pi) U M P Q

  34. Future Directions

  35. Future Directions • Implementation • Better Security Model? • Less trust on the Bank? • Multi-unit Coins? • Negative Coins?

  36. Thank you

More Related