1 / 42

Censorship-Resistant Publishing Systems

Censorship-Resistant Publishing Systems. Marc Waldman Computer Science Department New York University. What is a Censorship-Resistant Publishing System?. A system that maintains document availability in the presence of adversaries who wish to suppress the document.

duane
Download Presentation

Censorship-Resistant Publishing Systems

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. Censorship-Resistant Publishing Systems Marc Waldman Computer Science Department New York University

  2. What is a Censorship-Resistant Publishing System? A system that maintains document availability in the presence of adversaries who wish to suppress the document.

  3. Why Censorship-Resistant Publishing? • Political Dissent • “Whistleblowing” • Human Rights Reports

  4. Possible Solutions • Collection of WWW servers - CGI scripts to accept files - each file replicated on other participating servers • Usenet - Send file to Usenet server - Automatically replicated via NNTP

  5. Small group of WWW servers • Censorship-resistant properties - replication of content - multiple administrators • Problems - Small static set of servers - Flooding - Overwriting or deleting - Name Squatting

  6. Usenet • Censorship-resistant properties - globally distributed (resists admin threats) - huge capacity (resists storage flooding) • Problems - published document (article) short lived - propagation time unpredictable - no tamper check mechanism - cancel/supercede requests - easily filled with meaningless articles

  7. Document Availability Threats • Legal and illegal threats against server admin • Adversarial content modification • Document Flooding • Legal and illegal threats against publisher • Name Squatting • Malicious hosting servers

  8. “Eternity Service” Proposal • Worldwide collection of servers that store documents (prevents legal threats) • Publisher pays (anonymous e-cash) for document to be published on random subset of servers (prevents document flooding) • Once published, document can’t be deleted (prevents illegal threats against publisher) • Request and receive documents via anonymous communication channel (protects readers)

  9. “Eternity Service” Design Challenges • Servers - Adding, removing, adversarial servers • Document Naming - name squatting, updating, searching • Replica Placement - efficient retrieval

  10. “Eternity Service” Design Challenges • Content Storage - File or block based storge, encryption • Tamper Protection - Detect malicious & accidental tampering • Untraceable Communication Channel - “Real-time” or e-mail based

  11. Eternity Service Inspired Censorship-Resistant Systems • Design goals similar to Eternity Service • Scaled down design, some implementations available - Janus - Rewebber - Usenet Eternity - Freenet - FreeHaven - Publius - Tangler

  12. Janus • Provides URL rewriting service to hide true location of WWW page • Based on public key cryptography Ek (U)=Encrypt URL U with public key k U=http://www.cs.nyu.edu/ • Janus URL hides true location of U http://www.rewebber.de/surf-encrypted/Ek(U) • Janus acts as HTTP proxy, retrieving and rewriting pages.

  13. Janus In Action User 1 http://www.rewebber.de/surf-encrypted/Ek(U) 4 Janus index.html with URLs encrypted 2 http://www.cs.nyu.edu 3 Internet index.html

  14. Janus For Censorship-Resistant Publishing • Must trust Janus not to divulge true URL • Not fault-tolerant - Janus URL encodes single server - Access available only through Janus • Janus controls all returned content - Content could be modified or censored

  15. Taz and Rewebber • Collection of volunteer servers - Each has public/private key pair - Public keys well known to all users - Each runs a special HTTP proxy server • URL to hide is encrypted using layered technique - Similar to onion-routing - Results in long URLs • TAZ servers translate names to URLs

  16. Rewebber Layered Encryption Publisher uses public keys of servers to encrypt URL “nyu.edu” Want URL to be hidden behind 5 other servers. Encrypt in reverse path order (use public key of server 5 first) Server 1 Server 2 Server 3 Server 4 Server 5 nyu.edu LongURL MediumURL SmallURL http://VeryLongURL

  17. Taz and Rewebber In Action TAZ Server User 1. Apple_Pie_Recipe.taz 2. http://VeryLongURL 3. http://VeryLongURL 5 4 MediumURL LongURL 6 SmallURL 7. get recipe.html ApplePie.com

  18. Rewebber For Censorship-Resistant Publishing • Do not need to trust single entity - Single coopering server hides true URL • Allows anonymous retrieval - No limit on URL size - Padding can be applied after each decryption • Not fault tolerant - Single faulty or malicious server can prevent document from being retrieved • No tamper protection mechanism - A server can modify content on return trip

  19. Publius • Collection of volunteer servers - Each server donates disk space - Runs script to interpret Publius commands • Publication process encrypts document - encrypted document stored on subset of servers - part of encryption key stored with document • Publication process results in a Publius URL - Tells location of encrypted documents - Provides tamper check mechanism • Provides secure update and support for mutually hyperlinked content

  20. Cryptographic Hash A function that takes an arbitrary sized input and maps it to a fixed sized output value such that • It is computationally infeasible to find a specific input that matches a pre-specified output • It is computationally infeasible to find any two distinct inputs that map to the same output MD5 cryptographic hash output = 128 bits SHA-1 cryptographic hash output = 160 bits

  21. Publius Servers Publius Server Table www.redcross.org whitehouse.gov whitehouse.gov www.redcross.org library.fr library.fr www.nyu.edu www.nyu.edu publius.uk publius.uk

  22. Publish Operation D = Document To Publish K=Encryption Key Shamir Secret Sharing K Share1 Share2 Share3 Share4 MD5 ( D . Sharei ) Mod 5 = Index Into Server Table Index 3 = www.nyu.edu Store D encrypted under K, and Sharei on www.nyu.edu

  23. Publius URL Cryptographic hash value determines location of document. MD5 ( D . Sharei ) Mod 5 = Index Into Server Table To Form Publius URL – Perform hash on each Share and concatenate resulting MD5 values. http://!publius!/1e6adsg673h0=hgj7889340=yareyoureadingthis=12asbnm8945 The URL is cryptographically tied to document. Provides a tamper check mechanism.

  24. Publius Retrieve Operation • Break apart URL to discover document locations • Retrieve encrypted document and share from k locations • Reassemble Key K from shares • Decrypt retrieved document • Check for tampering • View in WWW browser • All work done by a client-side HTTP proxy

  25. Publius For Censorship-Resistant Publishing • Fault tolerant – don’t need all shares or documents to retrieve document • Tamper resistant – All documents retrieved from servers are checked for tampering • Encryption protects hides content from someone who doesn’t know URL (including server admin) • Scalability problems – Everyone needs list of servers • Flooding can be a problem. Publius file size limit is 100K.

  26. The Tangler Censorship-Resistant Publishing System • Designed to be a practical and implementable censorship-resistant publishing system. • Addresses some deficiencies of previous work • Contributions include – - A unique publication mechanism called entanglement - The design of a self-policing storage network that ejects faulty nodes

  27. Tangler Design • Small group (<100) of volunteer servers • Each server has public/private key pair • Each server donates disk space to system (publishing limit) • Agreement on volunteer servers, public keys and donated disk space • Published documents are divided into equal sized blocks, and combined with blocks of previously published documents (entanglement) • Entangled blocks are stored on servers • Each server verifies other servers compliance with Tangler protocols

  28. Tangler Goals • Anonymity – Users can publish and read documents anonymously • Document availability through replication • Integrity guarantees on data (tamper & update) • No server is storing objectionable documents - Decoupling between document and blocks - Blocks not permanently tied to specific servers - Server cannot chose which blocks to store or serve • Misbehaving servers should be ejected from system

  29. Publish Operation • Document broken into data blocks • Data blocks transformed into server blocks • Server blocks combined with those of previously published server blocks (entanglement) • Entangled server blocks are stored on servers Server Blocks Previously Published Server Blocks Data Blocks New Server Blocks Entangle +

  30. Document Retrieval Operation • Retrieve entangled server blocks from servers • Entanglement is fault tolerant – don’t need all entangled blocks to re-form data blocks • DisEntangle Operation re-forms original data blocks Entangled Server Blocks Data Blocks DisEntangle

  31. Block Entanglement Algorithm • Utilizes Shamir’s Secret Sharing Algorithm - Given a secret S can form n shares - Any k of them can re-form S - Less than k shares provide no information about S • Entanglement is a secret sharing scheme with n=4 and k=3 • Two shares are previously published server blocks • Two additional shares are created

  32. Benefits Of Entanglement • Dissociates blocks served from documents published - Single block belongs to multiple documents - Servers just hosting blocks • Incentive - Cache server blocks of entangled documents - Monitor availability of other server blocks - Re-inject blocks that have been deleted

  33. Tangler Servers (Tangle-Net) • All servers fall into one of two categories – non-faulty = follow Tangler protocols faulty = servers that exhibit Byzantine failures • All non-faulty servers are synchronized to within 10 minutes of correct time. • Time is divided into rounds (24 hour period) - Round 0 = Jan 1, 2002 (12:00AM) • Fourteen consecutive rounds form an epoch

  34. Tangler Round • Round Activity (concurrent actions) - Request storage tokens from other servers - Grant storage tokens to other servers - Send and receive blocks - Monitor protocol compliance of other servers - Process join requests - Entangle new collections and retrieve old collections • End of round - Commit to blocks received from servers (Merkle Tree) - Generate public/private key pair for the round - Broadcast next round commitment and public key

  35. Storage Tokens • Two step protocol to store blocks • First Step - Acquire storage tokens - Every server entitled to number of storage tokens from every other server - Tokens acquired non-anonymously, requests are signed by requestor • Second Step – Redeem Token - Send block & token anonymously to storing server - Anonymous communication supported by Mix-Net

  36. Storage Token Request • Server A wants to store block 92180 on Server B • Server A creates a blinded request for a token • The blinded request is sent to server B • Server B signs the request and returns it to A • Server A unblinds request obtaining the token Server A Server B XXXXX 92180 Server A XXXXX 92180 Server B Server_A_Tokens-- Unblind Token

  37. Redeeming A Token • Server A sends token & block through Mix-Net to B • Server B checks token signature, stores block, and returns signed receipt over Mix-Net • Server B commits to hash tree of all blocks Server A Server B Mix-Net 92180 storage receipt block 92180 Server B

  38. Membership Changes • At end of epoch all non-faulty servers perform Byzantine Consensus algorithm • Each server can vote out any other members • New servers can join at any time but must serve as a storage-only server for a probationary period of two complete epochs • A probationary server is admissible if it was not ejectable for at least two consecutive epochs. • Majority vote wins

  39. Threats • Majority of servers are adversarial - Adversarial servers join - Force non-faulty servers off • Publishing server discovery - Force suspected server off network - Should be able to republish on another server but may not have same credit limit • Probabilistic failure (difficult to remove)

  40. Summary • There is a need for censorship-resistant publishing tools. • Several systems have been proposed and some have been implemented. • Each system has strength and weaknesses. System design is greatly influenced by your adversary model.

  41. Publius and Tangler URLs • Publius www.cs.nyu.edu/~waldman/publius.html • Tangler www.scs.cs.nyu.edu/tangler

More Related