Rumor Riding, IEEE ICNP2006, Jinsong Han & Yunhao Liu, HKUST, Nov 12 1 Rumor Riding Anonymizing Unstructured Peer- to-Peer System Jinsong Han and Yunhao

1Rumor Riding, IEEE ICNP2006, Jinsong Han & Yunhao Liu, HKUST, Nov 12

Rumor RidingAnonymizing Unstructured Peer-

to-Peer System

Jinsong Han and Yunhao Liu

Department of Computer ScienceHong Kong University of Science and Technology


Privacy the right to be let alone: one of the

rights most cherished by people. Who is talking to whom should be

confidential or private in the Internet.

Who is searching a public database?

Which movie are you downloading?

Which companies are collaborating?

Who are you talking to via e-mail?


However… Your machine’s IP uniquely identifies you across web sites. Nothing illegal about cross-referencing. The goal of Internet anonymity: A host can communicate

with a server while nobody can determine its identity

www.ticket-agency.com

www.insurance-advertisement.com


Anonymous Routing

Anonymity is the state of being indistinguishable from other members of some group. Don’t know Who is Searching or Downloading What from Whom.

Main goal is to provide mechanism for routing that hides initiator’s and responder’s IP address.

Not trying to protect content of message.


Previous Approaches:Mainly Path-based

I

B

CA

R

Rumor Riding, IEEE ICNP2006, Jinsong Han & Yunhao Liu, HKUST, Nov 12

IPD C

IPC

B

Path-based Examples: Mix & Onion

A B C D

IPD

IPC

IPB

IPD

MIPC IPD M D CB

IPD M D C

IPC

M D

ABCD

Public keys IP


APFS: Mutual AnonymityServer

Client


Why NOT path-based? Path based

Difficulty in path construction and maintenance Cryptographic computation overhead is high:

RSA-based Vulnerable to many attacks


Basic Goals: A New Mutual Anonymity Protocol for P2P Non-path based Approach

No need to collect public keys for pre-construct a “secured path”

Changing delivery paths often Eliminating path maintenance overhead

Lightweight: Symmetric key only


Query and Downloading in Unstructured P2P Systems Flooding based query Reversed path based response Direct downloading

InitiatorQueryResponderResponseDownloading


Our Design: Rumor Riding

Initiator I

Cipher rumor Key rumor

sower sa

Flooding

Responder

C=Encrypt( q )KC K

IPsaq

q, IPsa


Response

Initiator I

Responder

Response key rumor

Reversed Path of key rumor

Response cipher rumor

sower sb

TCP Link

sower sa

Reversed path of cipher rumor

IPsa

IPsbRe


Confirm

Initiator I

Responder

Reversed path of responsekey rumor

Reversed path of response cipher rumor

sower sb

Confirm cipher rumor

Confirm key rumor

sower sc

TCP Link


File Delivery

Initiator I

Responder

Data rumorData rumor

Data rumor

sower sd

TCP Link

sower sa

Data rumor


Several Important Issues

Setting of rumors Can rumors meet? Ideal collision distance? How many sowers and where are they?

Overhead Traffic overhead Cryptographic overhead

Response time of queries


Trace Driven Simulation Physical network: BRITE, 30,000 -

100,000 nodes Overlay network: real traces, within 105

nodes (Clip2 and Ion P2P ) Each peer issues 0.3 queries per minute Peer dynamically coming and leaving

Mean: 10 minutes


Collision Rate

Theoretical vs. Simulation -The collision rates in the P2P topology are usually higher than

the theoretical results-The suggested number of rumors k and TTL value of each rumor

(also the path length of each rumor) L is k × L ≥ 100


Collision Distance

If L is larger than 25 (1 ≤ k ≤ 6), the average collision distance is no less than 5

When the rumors’ TTL value L is larger than 30 for k = [1..6], over 90% sowers have a collision distance larger than 5

L > 30 and 1 ≤ k ≤ 6 can effectively guarantee the safe collision distance and approximate random distribution of sowers.


Sower Number

At the least a number of sowers for each query, but obviously too many sowers will lead to heavy overhead

Each (k, k)-Rumor Riding scheme has no more than 10 sowers when k × L ≤ 200

k × L should be in a range [100, 200] in order to meet both the reliability and the scalability requirements

0 20 40 60 80 1000

10

20

30

40

50

Path length of rumors

Num

ber

of s

ower

s

(1,1)-RR(2,2)-RR(3,3)-RR(4,4)-RR(5,5)-RR(6,6)-RR


Traffic Overhead

0 2 4 6 8 10x 106

0

20

40

60

80

100

Average extra traffic overhead per query

Cum

ulat

ive

prec

enta

ge o

f que

ries

(%)

Shortcut(1,1)-RR(2,2)-RR(3,3)-RR(4,4)-RR(5,5)-RR(6,6)-RR

The (6, 6)-RR is the only one larger than the Shortcut (ICDCS’03) in the average traffic cost


Response Time

0 500 1000 1500 2000 25000

0.2

0.4

0.6

0.8

1

Response time (ms)

Cum

ulat

ive

prec

enta

ge o

f que

ries

(%)

0 500 1000 1500 2000 25000

0.2

0.4

0.6

0.8

1

Response time (ms)

Cum

ulat

ive

prec

enta

ge o

f que

ries

(%)


0 500 1000 1500 2000 25000

0.2

0.4

0.6

0.8

1

Response time (ms)

Cum

ulat

ive

prec

enta

ge o

f que

ries

(%)


Multiple rumor scheme would reduce the response latency effectively

Also incur more traffic overhead and message replications


Cryptographic Overhead

0 20 40 60 80 100102

103

104

105

Path length

Proc

essi

ng o

verh

ead

ShortcutRumor riding(k<7)

0 20 40 60 80 100102

103

104

105

106

Path lengthP

roce

ssin

g ov

erhe

ad

ShortcutRumor riding(k<7)


Prototype Implementation Experience

TABLE I Throughput of Algorithms

Algorithms Throughput (Mbytes/s)

128-bit AES key generation 0.217±0.00443

128-bit AES Encryption 8.155±0.256

CRC-32 calculation 137.48±4.79

1024-bit RSA Encryption 0.148±0.00280

1024-bit RSA Decryption 0.00670±0.000126

Examined the throughput of algorithms Key generation, 128 bits AES En/Decryption,

CRC-32, 1024bits RSA En/Decryption


Thank you !

Jinsong Han and Yunhao LiuHKUST


Background


Peer-to-Peer Model (P2P) Peer to Peer(P2P)

Fully utilizing the resource of the whole system

Peers are both clients and servers in an overlay network

Unstructured P2P architecture Centralized, Decentralized, and Hybrid


Responder

Broadcasting Based Broadcast or multicast Using the receivers’ public key to

encrypt the message P5 (S&P’02)

Initiator


Anonymity GuaranteesMessage coding attack Withstands attacks

Local collaborating attack Withstands unless all neighbors are malicious

Timing attack Withstands attacks

Traceback attack Withstands unless global adversary

Predecessor attack Withstands attacks

Traffic analysis attack Withstands attacks


Message Coding Attack Attackers analyze the message coding

format Especially effective to fresh nodes

The fresh node would lose its anonymity immediately if sending first plaintext query to the observer.

Solving method: encryption RR uses AES encryption and split the message into

two parts. Any single rumor will not expose the information of the query.


Local Collaborating Two collaborating adversaries could be neighbors

of the initiator. To confuse the local adversaries, a sower selects a

subset of its neighbors to send the plaintext query, and the two collaborating nodes will not receive the (plaintext+cipher/key).

kc

ba

I s

baI and s will not send the plaintext query to a and b


Time and Traffic Analysis Check the correlation between two traffics

P1 PnI R

k K+1

∆t

K’ K’+1

∆t’

12

k1

2k

Time difference

Packet number account

Latency analysisClogging packets

Shaping the traffic……

1:00 1:05 1:20 1:25


Invulnerable to Timing & Traffic Analysis Attack

The random walking property of rumors make it hard to build the correlation of traffics

Messages of a query cycle are not belonging to a same traffic

No continuous path in RR


Predecessor Attack Predecessor attack

An initiator repeatedly communicates to a specific responder in many rounds

Adversaries simply log any node that sends a message to the path

In this case, the initiator is most likely the one which appears more

RR Rumors correlating to a message walk randomly and

interact with random sowers unpredictably Sowers are not fixed

Documents

Rumor Riding, IEEE ICNP2006, Jinsong Han & Yunhao Liu, HKUST, Nov 12 1 Rumor Riding Anonymizing Unstructured Peer- to-Peer System Jinsong Han and Yunhao