Freenet A Distributed Anonymous Information Storage and Retrieval System I Clarke O Sandberg I Clarke O Sandberg B WileyT W Hong

Introduction Design goals 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

Features –Responds adaptively to usage patterns –Files are moved transparently, replicated and deleted without centralized location indexes –It operates at application layer –Assumes the existence of a secure transport layer

Security Issues How to provide anonymity? 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

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

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

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

Retrieving Data User hashes a short descriptive string to obtain file key User hashes a short descriptive string to obtain file key She then sends the “Request” message to her own node She then sends the “Request” message to her own node If present, returns with message saying it was the source 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 If not, looks up nearest key in routing table and forwards to the next node

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

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

Storing (Inserting) Data Similar to requesting data Similar to requesting data User picks a text string(title) and hashes it to a file key and sends it to her node 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 there is a collision, user is informed If no collision, node sends to the closest key in routing table If no collision, node sends to the closest key in routing table

This goes on until hops-to-live is reached 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 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 If not, the file is sent and copied at each node

Effects 1. New files tend to end up near files with similar keys enabling efficiency 2. New nodes can inform the network of their existence 3. An attacker trying to insert a corrupted or empty file under the same key will actually spread the real file further

Managing Data Node storage uses a LRU cache Node storage uses a LRU cache When a new file arrives, by insert or request, the least recently used file is removed 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 Thus, if a file is needed, it will remain on some node Or it will fade away Or it will fade away

Naming, Searching, Updating Possible Name collisions are a problem Possible Name collisions are a problem Solutions :- Solutions :- –Introduce two level structure, wherein Real files are stored under a unique key –An indirect file consists of a list of binary keys corresponding to that name and a search is made –Protects against malicious attacks of replacement

Insertion Insertion –Author can insert a no. of indirect files with pointers to real files –Collisions could be accepted in these files and be a sort of library of similar text titles –Private key encryption and public key decryption could be used to get info –Indirect file could also inserted under a signature verifying key

Performance Networks of 500 – 900 nodes Networks of 500 – 900 nodes Each with a datastore size of 40 items Each with a datastore size of 40 items Routing table size of 50 addresses Routing table size of 50 addresses 10 unique items stored in each node 10 unique items stored in each node

Security Primary Goal – To provide anonymity of requestors and inserters of files Primary Goal – To provide anonymity of requestors and inserters of files Receiver anonymity may be viewed as key anonymity Receiver anonymity may be viewed as key anonymity In Freenet routing depends on the key, so it is not possible In Freenet routing depends on the key, so it is not possible Hashes of keys may be used Hashes of keys may be used

Sender Anonymity Sender Anonymity –A node does not know whether it’s downstream neighbor is the actual source or forwarding it –A statistical analysis of network traffic may help the attacker in determining the source –Depth value may also help in determining the source

To prevent an eavesdropper, user should use the node on her own machine as the first point of entry To prevent an eavesdropper, user should use the node on her own machine as the first point of entry Messages between nodes are encrypted Messages between nodes are encrypted Pre routing can be added by encrypting with a succession of public keys Pre routing can be added by encrypting with a succession of public keys This determines the route of the encrypted message This determines the route of the encrypted message

Denial of Service Attacks Denial of Service Attacks –Insert a lot of garbage files –Use the Hash Cash scheme to prevent against this –Divide storage into two sections – one for new inserts and one for ‘established’ files –Protects against a person trying to spread garbage files –Difficulty in introducing genuine new files

Conclusion This scheme keeps information anonymous and is highly scalable This scheme keeps information anonymous and is highly scalable Provides effective means of storage and retrieval Provides effective means of storage and retrieval More rigorous tests with many more nodes and improvements to the basic protocol are required More rigorous tests with many more nodes and improvements to the basic protocol are required

Gnutella Many similarities exist between Freenet and Gnutella Many similarities exist between Freenet and Gnutella Everyone is visible to everyone else as long as you are ‘online’ Everyone is visible to everyone else as long as you are ‘online’ Users are split up into groups Users are split up into groups Gnutella employs a broadcast search for files which grows exponentially Gnutella employs a broadcast search for files which grows exponentially

Napster Napster has a centralized server, which does not store any data Napster has a centralized server, which does not store any data It coordinates searches of users It coordinates searches of users Security risk – Security risk – –If centralized server is shut down, no way of distributing files –The law!