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

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.


But, better assume it is honest-but-curious


It knows who gives a reputation point to whom, but is
assumed to keep the information secret.
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
RepCoinWithdraw
U
P
RepCoinDeposit
Award
Q
M
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
RepCredRequest
U
P
ShowReputation
Q
M
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 (S, pi)
EC.Withdraw()
EC.Deposit()
W
U
P
(S, pi)
EC.Spend()
Q
M
Reputation showing process
Bank
AC.GrantCred()
cred
U
P
AC.VerifyCred()
Q
M
Caveat

The problem lies in achieving unlinkability


E-cash is not enough
only provides privacy on the awarding side.
Caveat: Reputation granting
process
Bank (S, pi)
EC.Withdraw()
EC.Deposit()
W
U
P
(S, pi)
EC.Spend()
Q
If Bank and U collude, they will know Q
belongs to M
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 sig
(S, pi)
BS.Sign()
C
W
U
P
(S, pi)
BS.Verify()
Q
M
Future Directions
Future Directions


Implementation
Better Security Model?



Less trust on the Bank?
Multi-unit Coins?
Negative Coins?
Thank you