Security of P2P Systems Faraz Makari March 6, 2008 Seminar on - - PowerPoint PPT Presentation

Faraz Makari

March 6, 2008

Security of P2P Systems

Seminar on Advanced Topics in Distributed Computing WS 07/08 MPI-SWS (Saarland University), Petr Kuznetsov

1.

Motivation

2.

Introduction

3.

Secure Routing

4.

Fairness and trust

5.

Secure lookup protocol

6.

S-Chord

1.

Motivation

2.

Introduction

3.

Secure Routing

4.

Fairness and trust

5.

Secure lookup protocol

6.

S-Chord

Motivation I

Examples of structured p2p overlays:

CAN Chord Pastry Tapestry

Some applications:

Network storage Content distribution Web cashing, searching and indexing Applicaion level multicast

Security of P2P Systems

4

Motivation II

Examples of structured p2p overlays:

CAN Chord Pastry Tapestry

Some properties:

High availability and Scalability Decentralized and self-organizing Effective load balancing Highly resilient But, not secure

Security of P2P Systems

5

Motivation III

Example of some attacks:

Malicious nodes might give erroneous response to a reguest:

• At the application level: returning false data -> censor the data
• At the network level: returning false routing -> partition the

network

They might try to analyse the traffic againt system that try to

provide ananymous communication

Fairness: gain more from the network than give back to it:

• in terms of disc space
• in terms of bandwidth

Trust

Security of P2P Systems

6

1.

Motivation

2.

Introduction

• 1. Abstract m odel
• 2. Pastry
• 3. Tapestry
• 4. CAN
• 5. Chord
• 6. System m odels and assum ptions

Security of P2P Systems

7

Abstract m odel

Each peer has an identifier (e.g.,128-bit): nodeId

Unique and randomly distributed

E.g., by a hash-function, applied on the IP-address

Objects are assigned keys, selected from the same id

space, mapped to a unique live node (key‘s root)

Nodes maintain a routing table (incl. a neighbor set) Copies of the objecs are stored at replica roots

Routing

The messages are routed to the node whose nodeId is

numerically closest to the key

Security of P2P Systems

8

Pastry I

Security of P2P Systems

9

Pastry II

Message routing:

Route(key k)

Case 1)

nodeId i nodeId j

Case 2)

if no such node found, then the current node or its neighbor is the destination

Expected number of routing hops: <

j shares at lest one digit (or b bits) with k more than i, or j is numerically closer to k than i

Security of P2P Systems

10

Pastry III

Security of P2P Systems

11

Tapestry

Very similar to Pasrty Differences to Pastry:

No neighbor set Other message forwarding mechanism

(surrogate routing): Forwards the message to the node with the next higher value in the nth digit modulo

expected number of routing hops: Replica function produces random keys for

storing replicas

Security of P2P Systems

12

CAN

Some properties:

Entries in the node i‘s routing tables are

neighbors in a d-dimensional space.

Each node is reachable in (d/4)

routing hops in average.

Replica function produces random keys for

storing replicas.

As N increases, the size of the routing table does

not grow, but the number of routing hops.

Security of P2P Systems

13

Chord I

Nodes have m-bit IDs on an “identifier ring”(e.g.,

m=160)

Nodes maintain a “finger table” Each node points to up to 160 other nodes The ith entry refers to the live node with the samllest

id clockwise from

Each node points to its predecessor and n successors Replicas are stored in the neighbor set of the key’s

root

Expected number of routing hops:

Security of P2P Systems

14

Chord II

Security of P2P Systems

15

System m odel and assum ptions

N: # nodes in the network We assume

• fraction f of faulty nodes
• constrained-collusion Byzantine failure model
• Size of coalitions of faulty nodes bounded by cN (1/N ≤ c ≤ f)
• Static IP addresses

Two communication types:

1.

network-level: direct communication without routing the overlay, and

2.

• verlay-level: where messages are routed through the overlay using
• ne of the protocols

Cryptographic techniques (to prevent adversaries from observing or

modifying network-level communication between correct nodes)

Any message sent by a correct node to a correct destination over an

• verlay with no faulty nodes in delivered within time D with PrD

Security of P2P Systems

16

1.

Motivation

2.

Introduction

3.

Routing in p2p system s

1.

Secure routing

2.

Secure nodeId assignm ent

• Attacks&Solutions

3.

Seure routing table m aintenance

• Attacks&Solutions

4.

Secure m essage forwarding

• Attacks&Solutions
• Routing failure test
• Redundant routing
• Self-certifying data

Security of P2P Systems

17

Secure routing I

Definition:

Rk: set of nodes that contains, for each member of the set

• f replica keys associated with k, a live root node that is

responsible for that replica key.

Example in the Pastry: set of live nodes with nodeIds

numerically closest to the key

The secure routing primitive ensures that:

when a non-faulty node send a message to a key k, the message reaches all non-faulty members in the set of replica roots Rk with a very high probability.

secure routing primitive +

• ther security techniques
• > secure application

secure routing primitive +

• ther security techniques
• > secure application

Security of P2P Systems

18

Secure routing II

Secure routing ensures that:

(1) the message is eventually delivered, despite nodes that may corrupt, drop or misroute the message; and (2) the message is delivered to all legitimate replica roots for the key, despite nodes that may attempt to impersonate a replica root

Implementing the secure routing primitive requires:

(1) securely assigning nodeIds to nodes (2) securely maintaining the routing tables, and (3) securely forwarding messages

Security of P2P Systems

19

Secure nodeId assignm ent

Fundamental assumption: Secure nodeId assignment ensures that:

no attacker can choose the value of nodeIds of the nodes it controls We now represent som e attacks and their corresponding solutions

There is a uniform random distribution of nodeIds There is a uniform random distribution of nodeIds

Attacks & Solutions I

If an attacker can choose nodeIds, it might:

maximize the probability of appearing in the victim‘s routing table

partition the the Pastry and –chord overlay if it controls two disjoint

neighbor sets

control access to target objects by choosing the closest nodeIds to all

replica keys for a target object, thus controling all replica roots

• > it could delete, corrupt, or deny access to objects

If an attacker can obtain a large number of valid nodeIds easily

• > same problems above

Sybil attack Sybil attack

Security of P2P Systems

21

Attacks & Solutions II

Solution: certified nodeIds

• use CAs (certification authorities)
• CAs sign nodeId certificates
• nodeId certificates bind a random nodeId to the public key

associated with the node and its IP address Why do we need to include the IP addresses in certificates?

• at attacker with multiple valid nodeId certificates could swap

certificates among the nodes it controls,

• > it can increase the the fraction of bad nodes in those routing

tables

• hard to move nodeIds across nodes by binding the nodeId to IP

addresses, but

What about dynamic IP addresses? What about dynamic IP addresses?

Security of P2P Systems

22

Attacks & Solutions III

Certified nodeIds work well when we have fixed nodeIds

(in Chord, Pastry and Tapestry), but

hard to secure CAN where nodeIds represent a zone in a d-

dimensional space that split in half when a new node joins nodeIds change

Security of P2P Systems

23

Attacks & Solutions IV

Solution for Sybil attack:

(1) Make attacks economically expensive (2) Bind nodeIds to real world identities

Open problem:

Can we prevent such attackers without CAs, fees or identitiy checks?

Modeare the rate at which nodeIds are given out

Security of P2P Systems

24

Attacks & Solutions V

Some other methods: Use some crypto puzzles

example: require new nodes to generate a key pair s. t., the SHA-1 hash of the public key has the first p bits zero. Use a secure hash of the public key as their nodeIds Use different initialization vector for SHA-1. or use MD5 number of random bits in nodeIds will not be reduced

Security of P2P Systems

25

Attacks & Solutions VI

Some other methods:(cont.)

• periodically invaidate nodeIds, recompute new Ids using

another initialization vector

More overhead More overhead

Security of P2P Systems

26

Secure routing table m aintenance I

Secure routing table maintenance ensures that:

average fraction of bad entries in a routing table (= f) of a

correct node does not exceed

Note:

Bad routing updates increases f

We now represent som e attacks and their corresponding solutions

Security of P2P Systems

27

Attacks & Solutions I

Description:

The attacker may fake proximity to increase f

(e.g., in Pastry)

Example: Correct node p sends a probe to a bad node with certain nodeId

(to estimate the delay)

An attacker can intercept and have the bad node closest to p reply

to it

If the attacker controls enough bad nodes, then

it can make nodes that it controls appear close to p increase the probability that they are used for routing

Security of P2P Systems

28

Attacks & Solutions II

Solution: use more restrictive

communication model

For example, if nodes can only observe messages sent to

their own IP address, but

peers that have corporation with several offices around

the world could easily configure their routers appropriately

Security of P2P Systems

29

Attacks & Solutions III

Idea: It is hard to verify legitimate updates in Pastry &

Tapestry

Description:

The attacker may perform bad updates

(i.e., pointing to bad nodes)

Note: Pr [correct nodes receive updates from correct nodes] ≥ 1 - f Pr [correct nodes receive updates from bad nodes] ≤ f

Pr [faulty entry after an update] ≥ (1 - f) × f + f × 1 ≥ f

This effect cascades f 1 This effect cascades f 1

Security of P2P Systems

30

Perform ance vs. Security

Routing performance Constraints

• n nodeIds

Pastry Tapestry CAN Chord

Security of P2P Systems

31

Attacks & Solutions IV

• Solution: Constrained routing table
• Impose constraint on routing table entries
• Exapmle:
• Constrain each entry to be the closest nodeId to some point in the

id space (in Chord)

• Use two routing tables:

(1) locality-aware routing table

efficient routing

(2) Constrained routing table

high security use (2) if (1) fails

Security of P2P Systems

32

Attacks & Solutions V

Details in the context of Pastry:

(nodeId i)

Locality-aware routing table: The slut at level l and domain d can contain any nodeId that shares

the first l digits with i and has the value d in the l + 1st digit

Constrained Pastry routing table: The entry is constrained to point to the closest nodeId to a point p

in the domain

P is defined as follows:

It shares the first l digits with i has the value d in l + 1st digit, and the same remainig digits as i

Security of P2P Systems

33

Attacks & Solutions VI

• Message forwarding with constrained table as usual
• Initialization and maintenance as follows:

(1) new node n, ask a set of bootstrap nodes to send a

message with its nodeId as the key

(2) non-faulty nodes use the secure routing to obtain the

neighbor set for n

(3) n collects these sets and choose the „closest“ live

nodeIds from each

Security of P2P Systems

34

Attacks & Solutions VII

Problem of the constrained routing table: Obseravion: by inducion, for a node n, the entries in neighbor set point to entries that are close to a point p. Thus n can collect routing tables from its neighbor set, and pick the nodeId that is closest to the desired point for that entry. As a side effect, n informs its neighbor set of its arrival.

high

• verhead

high

• verhead

Security of P2P Systems

35

Secure m essage forwarding

Description:

Faulty nodes may:

drop the messages or, misroute the message or, Pretend to be the key‘s root.

Observation:

Pr [successful routing to a correct replica root | f ] =

independent of c

Routing with the constrained routing table is not sufficient !

Security of P2P Systems

36

Attacks & Solutions I

Solution: detect faults, use diverse routes

Secure routing primitive: given a message and a destination key, is ensures that with a very high probability at least one copy of the message reaches each correct replica root.

efficient implementation:

• apply failure test
• use redundant routing if the test returns positive

Security of P2P Systems

37

Routing failure test

given a key k and a set of prospective replica roots It returns:

Negative: the set is likely to be correct for k Positive: otherwise

Observation:

average density of nodeIds average density per unit of „volume“ > of faulty nodes

Idea: compare the densities of nodeIds

Security of P2P Systems

38

Routing failure test (in context of Pastry)

μp :average numerical distance

between consecutive nodeIds in the neighbor set of p Neighbor set of p contains:

• p
• l / 2 nodes with closest

nodeIds < p‘s

• l / 2 nodes with closest

nodeIds > p‘s rn = id0, …,idl+1 prospective neighbor set for key x

p checks that:

• all nodeIds in rn have

a valid certificate,

• the closest nodeId to

(1) x is the middle one,

• nodeIds satisfy the

definition of a neighbor set (2)

• μrn < μp × γ

Security of P2P Systems

39

Attacks & Solutions II

Attacks that weaken the routing failure test: Description:

The attacker can:

(1) collect certificates of nodes that have left the overlay to

increase the density of a prospective root neighbor set

(2) include nodeIds of nodes it controls and those of correct ones

in a prospective root neighbor set reduce the probability that the message reaches all correct replica roots

Security of P2P Systems

40

Attacks & Solutions III

Solution: the sender contacts all prospective root neighbors to determine if they are live and if they have a certificate that was omitted

The routing failure test is not very

• accurate. But we can trade off an increase

in α (false positive) to achieve a target β (false negative) The routing failure test is not very

• accurate. But we can trade off an increase

in α (false positive) to achieve a target β (false negative)

Security of P2P Systems

41

Redundant routing

Idea:

Route copies of the message over multiple routes towards each corresponding replica roots

It is used if the failure test returns positive How to ensure that the routes are different?

Ask the sender‘s neighbor set to forward the copies (e.g., CAN & Tapestry) Ask the sender‘s neighbor set to forward the copies (e.g., CAN & Tapestry) Use neighbor set anycast method (e.g., Chord & Pastry) Use neighbor set anycast method (e.g., Chord & Pastry)

Security of P2P Systems

42

Self-certifying data I

Data whose integrity can be verified by the client Reduce the use of securing routing primitive Examples of implementation:

Use a cryptographic hash of a file‘s content as the key

during insertion and lookup (as in CFS)

Insert signed files to the overlay (as in PAST)

• > extension:

store self-certifying group descriptor

Security of P2P Systems

43

Self-certifying data II

Group descriptor contanis:

the public keys IP addresses

• f the host responsible for replicating the object.
• The initail group is the set of replica roots associated the key.
• Read and write operation may require secure routing.
• Changing the membership requires secure routing and must

retain strong consistancy.

Security of P2P Systems

44

1.

Motivation

2.

Introduction

3.

Secure Routing

4.

Fairness and trust

5.

Secure lookup protocol

6.

S-Chord

Security of P2P Systems

45

Fairness I

Examples:

Fair sharing of disc space (in a distributed storage system)

Example:

Malicious nodes might wish to use more storage from the network

than they provide

solution 1) solution 2)

Quota architecture Quota architecture Quota authority Quota authority

Security of P2P Systems

46

Fairness II

Examples:

Fair sharing of network bandwidth

Example:

Bandwidth generated by some nodes in Kazaa Solution:

but

Use m icropaym ent system s Use m icropaym ent system s Scalability? Overhead? Scalability? Overhead?

Security of P2P Systems

47

Trust

• Two aspect of trust issue:

1.

Popularity: Problem: when queried documents do not contain the relevant information Example: „decoy“ Idea: rank documents

• 2. Code:

How trustable is the code written by third parties?

Security of P2P Systems

48

1.

Motivation

2.

Introduction

3.

Secure Routing

4.

Fairness and trust

5.

Secure lookup protocol

• 1. Introduction
• 2. Protocol
• 3. The Secure Routing Prim itive

4 . Spans

• 5. System operations

6 . Join&leave

• 7. Span split&m erge

8 . Span Takeover 9 . Overhead 10 .Security analysis 11.Conclusion

Security of P2P Systems

49

Secure lookup protocol

A preview of some efforts towards securing routing protocols:

Use redundant routing

assumption: # of malicious nodes ≤ ¼ of # of nodes

Group set of contiguous nodes into swarms

O(log² n) messages required (in S-Chord)

Map each node to its autonomous system (AS)

assumption: # of adversaries at most k but, no restriction on # of bad nodes within ASs

Security of P2P Systems

50

Introduction I

Assumptions:

Threshold cryptography using a system-wide

public/private key pair

Mobile proactive secret sharing (MPSS) Challenge:

Idea: when a (good) node receives a negative answer (e.g., lookup failure), it can challenge other nodes whether the provided routing data is correct.

Security of P2P Systems

51

Introduction II

Advantageous compared to prior approaches:

The lookup path has logarithmic complexity (easily) provable guarantees As long as challenges are correctly answered

(with high probability) the system state is not compromised

No limitations on the fraction of compromised nodes Instructive in its design and simplicity Very strong safety properties

high computational complexity high computational complexity

Security of P2P Systems

52

Protocol

System model:

Dynamic collection of nodes communicating with each other Oneway function h maps every node to a unique nodeId Unique nodeIds include IP address and public key

Assumtions:

nodeIds are random nodeIds are expensive nodes obtain join certificates from CAs each node can verify the join certificates fraction f of compromised nodes by adversaries in a

vulnerability window

Security of P2P Systems

53

The Secure Routig Prim itive

lookup(x):

• best-effort lookup operation
• returns a set of nodes of size t close to x in the id space

(neighbors of x)

Secure-lookup(x):

• returns a set of nodes of size t close to x in the id space
• correctness is guaranteed
• is invoked when lookup(x) doesn‘t return a satisfactory result

Security of P2P Systems

54

Spans

Dynamic partions of id space They can be split or merged Each span has a span committee Span committee is dynamic and responsible for:

keeping track of the span membership generating the span certificates

Security of P2P Systems

55

System operation (in the context of Pastry)

lookup(x): as usual, no correctness guarantee secure-lookup(x): with correctness guarantee

additionally:

• the reply includes the span certificate of

x, and

• to ensure the freshness of the certificate

the client issues a challenge

Security of P2P Systems

56

Join

The new node:

1.

• btain a join certificate

2.

ask a bootstrap node to perform lookup to ist id

3.

gets its span certificate and leaf set Challenge it wait until a new span is generated containig itself

How to verify the span validity? How to verify the span validity?

Security of P2P Systems

57

Leave

no yes

Detect and monitor when a neighbor has died or misbehaved Detect and monitor when a neighbor has died or misbehaved Contact span committee to generate a new certificate Contact span committee to generate a new certificate

Security of P2P Systems

58

Span Split and Merge

Our system ahs two parameters: (1) s min: minimum # of nodes in a span (2) s max: maximum # of nodes in a span # nodes > s max # nodes < s min

after join or leave after join or leave

split in half split in half merge merge

Security of P2P Systems

59

Span Takeover

Observation: f > 1/3 of nodes Idea: merge adjacent spans if liveness is violated

Span might experience

liveness problem

Span might experience

liveness problem

Security of P2P Systems

60

Span Takeover Span Takeover

Overhead

n: size of the span committee

• : cost of the share refreshment protocol

Amount of exchanged data during the re-key (1024 bit DSA private key):

• with 20 node committee

~ 8 MB

• with 16 node committee

~ 4 MB

Security of P2P Systems

61

Security Analysis

Eclipse attack:

a malicious node try to take over the neighborhood of a good node and isolating it from the system.

Data Erasure:

a good node i performs a lookup for item d, a malicious node j try to convince i that j belongs to the span responsible for d and d does not exist.

Security of P2P Systems

62

Conclusion

New machanism for securing DHTs Not fully optimized Periodic heavy overhead ( ) Good verifiable security properties Challenge mechanism as building block

Security of P2P Systems

63

1.

Motivation

2.

Introduction

3.

Secure Routing

4.

Fairness and trust

5.

Secure lookup protocol

6.

S-Chord

1.

Introduction

2.

Notation

3.

Required links

4.

Successor protocol

5.

Join protocol

6.

Conclusion

Security of P2P Systems

64

Introdution

• Standard attack model:

Random Byzantine attack: each peer suffers a Byzantine fault independantly at random with constant probability < ½ at some point of time

• Byzantine join attack:

(¼ - ε0)z Byzantine nodes join over a time period during which:

1.

total # of nodes ≥ z

2.

# of correct nodes joining and leaving ≤ (k: tunable parameter)

3.

computationally unbounded adversary with full information about the network

z-g ood interv a l z-g ood interv a l

Security of P2P Systems

65

Assum ptions & Results I

During any z-good interval for S-Chord with high probability, we achieve:

All functionality of Chord All functionality of Chord Rule-set („proper behavior“) for all peers Rule-set („proper behavior“) for all peers Less # of messages for lookup in expectation Less # of messages for lookup in expectation

Security of P2P Systems

66

Assum ptions & Results II

n peers in the network O(log² n) links at peer Latency Ecpected messages Lookup O(log n) Θ(log² n) Join Θ(log n) Θ(log³ n)

Security of P2P Systems

67

Basics I

Recall: successor (k), next (p, k) in Chord Extension of Chord to S-Chord: Notation: x, y: two points on the unit circle (its circumference = 1) y – x if y ≥ x d(x, y): 1 – x + y otherwise Faulty peer: controlled by an adversary Correct peer: follows the protocol

Security of P2P Systems

68

Security of P2P Systems

69

Basics II

Notation: 0 < random id ≤ 1 swarm: small set of peers working together as a single functional unit S(x): peers located within a clockwise distance of (C ln n / n) of the point x S(p) is good: it has ≥ ¾ coorect peers we assume that peers know n ! random ids

• ver a z-good interval

all swarms will be good with high probability

• ver a z-good interval

all swarms will be good with high probability

Security of P2P Systems

70

Reqired Links

Every peer p has links to all peers in:

Center Interval:

Center(p): peers є [p – (2C ln n)/n, p + (2C ln n)/n]

Forward Intervals:

Forward(p, i): peers є [p + /m - (C ln n)/n, p -

/m - (C ln n)/n]

for i є [1, log m-1]

Backward Intervals:

Backward(p, i): peers є [p -

/m - (C ln n)/n, p - /m + (C ln n)/n]

for i є [1, log m-1]

Security of P2P Systems

71

Successor protocol

Algorithm 1 SUCCESSOR(p) 1: p sends a request for k to all peers in S(p); 2: S ← set of all peers in S(p); 3: x ← identifier of p; 4: while (d(x, k) > (C ln n)/n) do 5: x′ ← next(x, k); 6: All peers in S send the request for k to all peers in S(x′); 7: S′ ← set of all peers in S(x′) that received the above request from a majority of the peers in S; 8: S ← S′; 9: x ← x′; 10: end while 11: The peers in S send back pointers to all the peers in S(k). These pointers are sent backwards along the same path, in the same manner to the peer p;

Security of P2P Systems

72

Join protocol I

Algorithm 2 JOIN(p) 1: Peer p contacts some correct peer q which notifies S(q) of p’s request to join; 2: All peers in S(q) both 1) come to consensus on a random number r ∈ (0, 1] and 2) select two random peer points, p1 and p2, uniformly at random from all peers currently in the DHT. Assume that r, p1, and p2 are ordered clockwise along the unit circle; 3: Using the SEND MESSAGE algorithm, all peers in S(p) notify peers in Center(p1) that p has joined the network and that p is taking the location of ρ1 who is relocating. In same way, all peers in S(p) notify peers in Center(p2) that p1 is joining and that p1 is taking the location of ρ2 who is relocating. Finally, all peers in S(p) notify all peers in Center(r) that ρ2 is joining;

Security of P2P Systems

73

Join protocol II

4: All peers in S(q) get pointers to the peers in Center(p1), using O(1) calls to the SUCCESSOR algorithm. All peers in S(q) send these pointers to p. In a similar fashion, S(q) sends pointers to the peers

• f Center(p2) to p1 and sends pointers to peers of Center(r) to p2;

5: The peers in Center(p1) send data items for all keys k such that p ∈ S(k) and p then stores copies of these data items. Similar processes for 1) Center(p2) and p1 and 2) Center(r) and p2 are performed; 6: PLACEMENT(p); 7: PLACEMENT(p1); 8: PLACEMENT(p2);

Security of P2P Systems

74

Join protocol III

Security of P2P Systems

75

Conclusion

Under certain conditions robust against

Byzantine join attacks

Rule set on the peers Θ(log² n) expected messages for SUCCESSOR O(log² n) links stored per peer Extendable to other ring based DHTs

Security of P2P Systems

76

Thank you!

Security of P2P Systems

77