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.

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

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

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

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

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

“Eternity Service” Proposal Worldwide collection of servers that store documents (prevents legal threats) 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 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 Once published, document can’t be deleted (prevents illegal threats against publisher) Request and receive documents via anonymous communication channel Request and receive documents via anonymous communication channel (protects readers) (protects readers)

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

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

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

Janus Provides URL rewriting service to hide true location of WWW page Provides URL rewriting service to hide true location of WWW page Based on public key cryptography Based on public key cryptography E k (U)=Encrypt URL U with public key k U= Janus URL hides true location of U Janus URL hides true location of U k (U) Janus acts as HTTP proxy, retrieving and rewriting pages. Janus acts as HTTP proxy, retrieving and rewriting pages.

Janus In Action Internet k (U) User Janus index.html with URLs encrypted

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

Taz and Rewebber Collection of volunteer servers 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 URL to hide is encrypted using layered technique - Similar to onion-routing - Results in long URLs TAZ servers translate names to URLs TAZ servers translate names to URLs

Server 1 Server 2 Server 3 Server 4 nyu.edu Rewebber Layered Encryption Server 5 LongURLMediumURLSmallURL 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)

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

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

Publius Collection of volunteer servers Collection of volunteer servers - Each server donates disk space - Runs script to interpret Publius commands Publication process encrypts document 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 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 Provides secure update and support for mutually hyperlinked content

Cryptographic Hash A function that takes an arbitrary sized input and maps it to a fixed sized output value such that 1) It is computationally infeasible to find a specific input that matches a pre-specified output 2) 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

Publius Servers whitehouse.gov library.fr publius.uk Publius Server Table publius.uk library.fr whitehouse.gov

Publish Operation D = Document To Publish K=Encryption Key Shamir Secret Sharing Share 1 Share 2 Share 3 K Share 4 MD5 ( D. Share i ) Mod 5 = Index Into Server Table Index 3 = Store D encrypted under K, and Share i on

Publius URL Cryptographic hash value determines location of document. MD5 ( D. Share i ) Mod 5 = Index Into Server Table To Form Publius URL – Perform hash on each Share and concatenate resulting MD5 values. this=12asbnm8945 The URL is cryptographically tied to document. Provides a tamper check mechanism.

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

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

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

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

Tangler Goals Anonymity – Users can publish and read documents anonymously Anonymity – Users can publish and read documents anonymously Document availability through replication Document availability through replication Integrity guarantees on data (tamper & update) Integrity guarantees on data (tamper & update) No server is storing objectionable documents 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 Misbehaving servers should be ejected from system

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

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

Block Entanglement Algorithm Utilizes Shamir’s Secret Sharing 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 Entanglement is a secret sharing scheme with n=4 and k=3 Two shares are previously published server blocks Two shares are previously published server blocks Two additional shares are created Two additional shares are created

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

Tangler Servers (Tangle-Net) All servers fall into one of two categories – 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. All non-faulty servers are synchronized to within 10 minutes of correct time. Time is divided into rounds (24 hour period) Time is divided into rounds (24 hour period) - Round 0 = Jan 1, 2002 (12:00AM) Fourteen consecutive rounds form an epoch Fourteen consecutive rounds form an epoch

Tangler Round Round Activity (concurrent actions) 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 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

Storage Tokens Two step protocol to store blocks Two step protocol to store blocks First Step - Acquire storage tokens 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 Second Step – Redeem Token - Send block & token anonymously to storing server - Anonymous communication supported by Mix-Net

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

Redeeming A Token Server A sends token & block through 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 checks token signature, stores block, and returns signed receipt over Mix-Net Server B commits to hash tree of all blocks Server B commits to hash tree of all blocks Mix-Net storage receipt block Server A Server B Server B

Membership Changes At end of epoch all non-faulty servers perform Byzantine Consensus algorithm At end of epoch all non-faulty servers perform Byzantine Consensus algorithm Each server can vote out any other members 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 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. A probationary server is admissible if it was not ejectable for at least two consecutive epochs. Majority vote wins Majority vote wins

Threats Majority of servers are adversarial Majority of servers are adversarial - Adversarial servers join - Force non-faulty servers off Publishing server discovery 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) Probabilistic failure (difficult to remove)

Summary There is a need for censorship-resistant publishing tools. There is a need for censorship-resistant publishing tools. Several systems have been proposed and some have been implemented. 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. Each system has strength and weaknesses. System design is greatly influenced by your adversary model.

Publius and Tangler URLs Publius Publiuswww.cs.nyu.edu/~waldman/publius.html Tangler Tanglerwww.scs.cs.nyu.edu/tangler