Censorship-Resistant Publishing Systems

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