Freenet

1
Freenet

• A Distributed Anonymous Information System and
  Retrieval System
• I. Clarke, O. Sandberg, B. Wiley, W. Hong

ECE 6102 Presented By Kaushik Chowdhury and
Justin Fiore
2
Presentation Outline

• Introduction of Freenet
• Protocol Overview
• Protocol Details
• Security Features
• Performance Evaluation
• Conclusions

3
P2P Architecture Features

• Decentralized model
• e.g. Freenet, Gnutella, Chord
• no global index local knowledge only
• contact mediated by chain of intermediaries

• Centralized model
• e.g. Napster
• global index held by central authority
• direct contact between requestors and providers

4
Freenet Timeline

• Final Year project Ian Clarke , Edinburgh
  University, Scotland, June, 1999
• Sourceforge Project, most active
• V.0.7 (Alpha release April 2006)
• Incorporates a new approach to anonymous
  peer-to-peer adopting a "scalable darknet"
  architecture.
• Source
  http//freenetproject.org/news.html

5
Introduction

• Design goals
• Producer and consumer anonymity
• Deniability for storers of information
• Resistance to hostile third parties
• Efficient dynamic storage and routing
• Decentralization of network functions

6
Security Issues

• How to provide anonymity?
• Consumers may use browser proxy services
• However, producers may keep session logs
• Contacting a particular server reveals the
  information needed
• Producers may ensure anonymity by using encrypted
  URL services
• No protection against the operator of the service

7
Architecture

• Peer to peer network of nodes that query one
  another
• Each node has its local data store and dynamic
  routing table
• Enables users to share unused disk space and
  increases the storage capacity of the network

8
Key Management

• A way to locate a document anywhere
• Keys are used to form a URI
• Two similar keys dont mean the subjects of the
  file are similar!
• Keyword-signed Key(KSK)
• Based on a short descriptive string, usually a
  set of keywords that can describe the document
• Potential problem global namespace

File Key
Public
Fn()
Descriptive string Eg. gatech/distributed_systems
Private
9
Key Management contd

• Signed-subspace Key(SSK)
• Add sender information to avoid namespace
  conflict
• Private key to sign/ public key to verify

Descriptive string Eg. gatech/distributed_systems
Private
Public
XOR
Fn()
Fn()
Hash 1
Hash 2
Fn()
File Key
10
Key Management contd

• Content-hash Key(CHK)
• Derived by directly hashing the contents of the
  corresponding file
• Used in conjunction with the signed-subspace keys
  

Fn()
11
Basic Model

• Nodes know only their immediate upstream and
  downstream neighbors
• Queries are given a unique identifier and
  hops-to-live count
• Queries are forwarded to a node based on previous
  information

12

• If a previous message is seen, forwarded to
  another node
• Process continues until file is obtained or
  hops-to-live counter is exceeded
• Success or Failure is passed back up the chain

13
c
a
Start
1
2
3
12
b
d
11
10
7
4
6
9
5
f
e
8
14
Retrieving Data

• User hashes a short descriptive string to obtain
  file key
• She then sends the Request message to her own
  node
• If present, returns with message saying it was
  the source
• If not, looks up nearest key in routing table and
  forwards to the next node

15

• If request is ultimately successful, node passes
  it back up the upstream requestor
• It also makes a local cache of the very same file
• Future requests will be serviced faster
• Similar keys will also be forwarded to the same
  node
• For security, any node along the path can claim
  to be the author of the file

16

• If a node cannot forward to its preferred
  downstream node, it sends to its second-nearest
  key
• If that doesnt match, then third nearest key and
  so on
• If none of them match, it sends a failure message
  to its upstream node which follows the same
  procedure

17
Storing (Inserting) Data

• Similar to requesting data
• User picks a text string(title) and hashes it to
  a file key and sends it to her node
• If there is a collision, user is informed
• If no collision, node sends to the closest key in
  routing table

18

• This goes on until hops-to-live is reached
• If a collision occurs anywhere, the node sends
  back the file along with a notice and is treated
  as a request
• If not, the file is sent and copied at each node

19
Managing Data

• Node storage uses a LRU cache
• When a new file arrives, by insert or request,
  the least recently used file is removed
• Thus, if a file is needed, it will remain on some
  node
• Or it will fade away

20
Node Joins

• Need to assign it a key that is not solely
  influenced by a given malicious node.

New node
Randomly chosen node
Address, Hash 1
Seed random()
Seed random()
Hash 1
XOR
Fn()
Fn()
Hash 1
Hash 2
21
Protocol Details

• 3 Basic Operations
• Handshake
• Request Data
• Insert Data

22
Transport Methods

• Transport
• Flexibility via use of TCP, UDP, or other
  technologies, such as packet radio
• Node addresses consist of a transport method and
  transport-specific identifier
• tcp/192.168.1.519114

23
Protocol Handshake

• Transaction begins with Request.Handshake
• Includes return address of sending node
• The sending node may or may not be the original
  node
• Remote node replies with Reply.Handshake
• Specifies protocol version that it understands
• Handshakes are remembered for a few hours

24
Request Data

• Terminates when
• Key is found (Send.Data message)
• Key is not found (Reply.NotFound message)
• Reply.Restart message sent when a remote node has
  waited for network timeouts while contacting
  other nodes. This message informs predecessor
  nodes to extend their timers.
• Reply.Continue is sent when a dead end is
  reached, and routing must backtrack.
• When key is found, that node sends the data back
  as well as the supplierAddress, where the
  supplierAddress is possibly faked.

25
Successful Data Request
26
Unsuccessful Data Request
27
Insert Data

• Terminates when
• Hops-to-live is 0 and key is not found
• Remote node sends Reply.Insert
• Hops-to-live is 0 and key is not found, but
  current node has a routing table entry for key.
• Remote node sends Reply.NotFound
• Key is found
• Remote node sends Send.Data including the data
  for the key.
• Request.Continue sent when no more nodes can be
  contacted and hops-to-live is nonzero

28
Successful Data Insert
29
Unsuccessful Data Insert
30
Security Goals

• Anonymity
• Anonymity of requestors of files
• Anonymity of inserters of files
• Plausible deniability
• Make it plausibly deniable that any node may or
  may not have requested, inserted or stored a
  given file.
• Integrity
• Prevent malicious removal of a file
• Prevent malicious modification
• Reliability
• Resist denial-of-service attacks

31
Degrees of Anonymity
Degree Description
Absolute Privacy Presence of communication cannot be perceived.
Beyond Suspicion The sender is no more likely to have originated the message than any other potential sender.
Probable Innocence The sender is no more likely to be the originator than not.
Possible Innocence The sender is more likely to be the originator than not.
Exposed The sender can be identified as the originator.
Provably Exposed The sender can be provably identified as the originator to a third party.
32
Anonymity Properties of Freenet
System Attacker Sender Anonymity Key Anonymity
Basic Freenet Local Eavesdropper Exposed Exposed
Basic Freenet Collaborating Nodes Beyond Suspicion Exposed
Freenet pre-routing Local Eavesdropper Exposed Beyond Suspicion
Freenet pre-routing Collaborating Nodes Beyond Suspicion Exposed
33
Freenet Anonymity Details

• Since routing depends on the keys, key anonymity
  cannot be achieved with basic Freenet
• Sender anonymity against a collaboration of nodes
  is preserved because any node that sends a
  message could be the originator or just
  forwarding the message

34
Freenet Anonymity Details (2)

• Sender anonymity against a local eavesdropper
  cannot be achieved because the local eavesdropper
  could perform traffic analysis on incoming and
  outgoing messages
• Also, the local eavesdropper could act as the
  first node in the query, so then the encrypted
  request would still be known to the eavesdropper

35
Freenet Anonymity Details (3)

• The depth and hops-to-live values could be used
  to locate the originator (or at least locate a
  set of possible originators)
• This is obscured by random selection initial
  depth and hops-to-live values
• Depth is incremented and hops-to-live is
  decremented probabilistically to further obscure
  the originator

36
Pre-Routing

• Basic Freenet messages are encrypted using a
  series of public keys, which determine the path
  of the pre-routing
• The message is forwarded along that route and
  decrypted partially at each node.
• When the message reaches the pre-routing
  endpoint, it is injected into Freenet normally
• The intermediate pre-routing nodes cannot read
  nor alter the request nor the originating node

37
Data Source Anonymity

• The data source field is probabilistically
  altered during transmission through the network.
• It is not possible to tell whether a node
  provided the file or was just forwarding it
• This provides plausible deniability because it is
  not provable whether or not a node had a file
  before an investigative node queried it for the
  specific file.
• This is because any request will cache the result
  along the return path.

38
Data Source Anonymity (2)

• In a normal situation, it would be possible to
  identify the existence of a file on a node by
  sending a request to that node with HTL 1
• Freenet solves this by probabilistically
  forwarding any message with HTL 1 to the next
  node.

39
Prevention of Modification

• Content-hash keys and Signed-subspace keys
• A (possibly signed) hash of the data accompanies
  the data
• Modification would require
• Finding a hash collision for content-hash keys
• Successfully forging a digital signature for
  signed-subspace keys
• Keyword-signed keys
• Keys are a hash of the original descriptive
  string.
• Vulnerable to dictionary attack
• Colliding keys can be made by anyone knowing the
  original descriptive string.

40
Denial-of-Service Attack Prevention

• Junk File Attack
• Attacker attempts to flood network with a large
  number of junk files
• Data store is divided into two parts new files
  and established files
• Inserts displace new files, not established files
• Junk File Attack would only paralyze inserts
  temporarily, not displace files that are desired

41
Denial-of-Service Attack Prevention (2)

• Alternate Versions Attack
• Attacker inserts alternate versions of files
  under the same keys of the file they want to
  displace
• Does not work against content-hash keys or
  signed-subspace keys without hash collision or
  digital signature forgery
• If done with a keyword-signed key, both versions
  of the file would coexist in the network.
• Solved by the insert protocol
• Every unsuccessful attempt to insert the
  alternate file further distributes the real
  files data across the network because Send.Data
  returned from the insert request.

42
Performance Evaluation

• Number of nodes 1000
• Datastore size 50 items
• Routing table size 250 addresses
• Ring lattice topology

43
Network convergence

• X-axis time
• Y-axis of pathlength
• 1000 Nodes, 50 items datastore, 250 entries
  routing table
• the routing tables were initialized to
  ring-lattice topology
• Pathlength the number of hops actually taken
  before finding the data.

44
Scalability

• X-axis of nodes
• Y-axis of pathlength
• The relation between network size and average
  pathlength.
• Initially, 20 nodes. Add nodes regularly.

45
Fault Tolerance

• X-axis Node Failure
• Y-axis Pathlength in hops
• The median pathlength remains below 20 even when
  up to 30 nodes fails.

46
Small world Model

• X-axis Number of links
• Y-axis Proportion of nodes
• Most of nodes have only few connections while a
  small number of news have large set of
  connections.
• Follows power law.

47
Conclusions

• Freenet provides a fairly anonymous file storage
  and retrieval medium.
• It uses an adaptive routing algorithm to fulfill
  queries, not a broadcast like Gnutella and
  others.
• Freenet was seen to be highly scalable in
  simulation results.