1 / 16

Freenet: A Distributed Anonymous Information Storage and Retrieval System

Freenet: A Distributed Anonymous Information Storage and Retrieval System. Presenter: Chris Grier ECE 598nb Spring 2006. Outline. Overview of Freenet Architecture and Protocol Performance Security Discussion. Freenet Design Goals.

lowri
Download Presentation

Freenet: A Distributed Anonymous Information Storage and Retrieval System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Freenet: A Distributed Anonymous Information Storage and Retrieval System Presenter: Chris Grier ECE 598nb Spring 2006

  2. Outline • Overview of Freenet • Architecture and Protocol • Performance • Security • Discussion

  3. Freenet Design Goals • Freenet is basically a P2P file system that supports anonymity for readers and writers. • Anonymity and deniability • Resistant to denial of service • Efficient • Completely Decentralized

  4. Keys and Use • 3 Keys for each file • Keyword-signed key (descriptive string) • Signed-subspace key (personal namespace) • Content-hash key (file contents) • KSK and SSK (public half only) are published to allow retrieval • CHK allows for updating the file, different CHK and same SSK cause collision

  5. More Keys and Use • The structure allows for users to have directories. • Using public/private key pairs allows only users who “own” the space to write files there • No centralized place to find keys. Must find them from someone who publishes. • Possible crawler • www publishing of hashes and keys

  6. Retrieval • If the file is not found locally, forwards the request on to the node with most similar key. • Prevents loops by moving down the list if a file is not found. • Hops to live reduces network load and keeps requests from progressing too far • Requests are cached • Reply message can have the data source changed during trip back to node that requested • Routing Improves over time • Caching of files replicates popular data closer to requests

  7. Storing • Calculate the keys and send an insert message. This is very similar to retrieval. • The hops-to-live here serves to check for collisions in the keys generated. • When a node inserts it checks for a collision along the path of insertion. • The file is stored along the initial path at all the hosts • New files with similar keys are put on hosts with other similar keys

  8. Management • Cache uses LRU policy • Files put in the system might not stay • All files are stored encrypted, provides plausible deniability only • Discussion: is plausible deniability at the node operator good enough?

  9. Joining the network • Uses out of band communication for initial join msg • Choose a random seed, send it. Once received the next node generates a random seed and XORs with the original, and continues the chain. • After last node generates seed, each host releases the seed for verification • Discussion: The structure of the network seems to depend somewhat on the initial node chosen. Isn’t this effected by the out of band communication?

  10. Performance and Scalability • Randomly constructed • Same cache size and routing table size at every node • The network improves over time as claimed. Path length of requests decrease • As network grows, path length scales like log • The effect of routing tables can be seen when the network gets very large.

  11. Security • Aims to protect readers and writers identity to an attack involving collaborating nodes • No data security, or assurance of data • Sender Anonymity protected “beyond suspicion”? • Without some analysis, this seems like a bold statement • “pre-routing” suggested, but seems like just another idea suggested • Some aspects of onion routing

  12. More Security • Source protection by randomly flipping the data-source field • Modification of files by attackers is prevented by the use of hashes and signatures (CHK and SSK) • If just stored by KSK, the namespace can be dictionary attacked • Resistant to junk insertion • Displacement of files requires private keys again.

  13. Attacks • Network construction • When hosts connect, there’s the possibility that an attacker can influence how the routes are setup. • Force the network to arrange itself in certain ways (this will change) • Want to determine who sent a message • With multiple compromised hosts, it seems possible might need to guess at topology? • More attacks?

  14. Discussion • Questions? • What are some possible attacks on the system? • Is the lack of search capability acceptable in a system like this? • Does the anonymity provided seem less than hoped for in a system like this? • Does Freenet lack some features you would expect in an anonymous publishing/retieval system? • What does Freenet have to offer over crowds?

  15. How essential is search? • A lot of unanswered questions in creating and being part of the system • “beyond suspicion” for collaberating nodes in the sender anonyminty • Somewhat inspiried by crowds the main difference here is the promise of security. • The authors and readers should be anonymous. • Scientology documetns being erradicated • Leaked Diebold source code

More Related