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

Reputation Systemsfor Anonymous

Networks

Seung Geol Choi

Columbia Universityjoint 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 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

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

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.

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.

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.

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

Security Model

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)

Operations - 1

Key Generation Algorithms Bank: Bkeygen() Peer’s Identity: Ukeygen() Peer’s Pseudonym: Pnymgen()

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.

Reputation granting process

Bank

U M

RepCoinWithdraw

Award

RepCoinDeposit

P Q

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

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

Reputation showing process

Bank

U MShowReputation

RepCredRequest

P Q

Security

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().

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.

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.

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.

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

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.

Our Construction

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.

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.

Reputation granting process

Bank

U M

EC.Withdraw()

EC.Spend()

EC.Deposit()

P Q

W

(S, pi)

(S, pi)

Reputation showing process

Bank

U MAC.VerifyCred()

AC.GrantCred()

P Q

cred

Caveat

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

Caveat: Reputation granting process

Bank

U M

EC.Withdraw()

EC.Spend()

EC.Deposit()

P Q

W

(S, pi)

(S, pi)

If Bank and U collude, they will know Q belongs to M

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.

Reputation granting process

Bank

U MP Q

W

(S, pi)

(S, pi)BS.Sign()

C BS.Verify()

sig

Future Directions

Future Directions

Implementation Better Security Model?

Less trust on the Bank? Multi-unit Coins? Negative Coins?

Thank you