Reputation Systems for Anonymous Networks

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