12.5 Anonymous publishing

The technologies overviewed and discussed so far address the problem of how to protect the privacy of Web users, and how to provide support for anonymous browsing. In this section, we address the problem of how to anonymously publish on the Web. The current WWW architecture provides little support for anonymous publishing. In fact, the architecture

fundamentally includes identification information in the URL that is used to locate resources, and it seems difficult to avoid revealing this information (at least if it is required that resources published anonymously be accessible from standard Web browsers without the need of specialized client software or anonymity tools). Also note that the browser privacy problem is orthogonal to the anonymous publishing problem, and that the two problems compose well: if full anonymity is needed, techniques for anonymous browsing must work in tandem with an infrastructure supporting anonymous publishing.

12.5.1 JANUS and the rewebber service

JANUS was a joint research project of the Forschungsinstitut f ¼r Telekommunikation-(FTK) of Dortmund, Hagen, and Wuppertal in Germany. One of the major results of the project was an anonymous publishing service that was first provided by the Fernuniversit t Hagen and later taken over by a spin-off company called ISL Internet Sicherheitsl sungen GmbH. More recently, the service name was changed from JANUS to Rewebber. ^[24]

In its current form, the Rewebber service provides anonymity services for both browsers and Web publishers (or Web servers, respectively):

In order to provide anonymity services for a browser, the Rewebber service acts as an anonymizing HTTP proxy server. It accepts requests from arbitrary browsers, removes all data that may reveal information about the requesting user , and forwards the requests to the Web servers. Similarly, the servers responses are relayed back to the appropriate browsers. Furthermore, the Rewebber service supports the SSL/TLS protocol.
In order to provide anonymity services for a Web publisher and to support anonymous publishing accordingly , the Rewebber service makes use of encrypted URLs that are part of nested URLs. This is explained in more detail below.

In Section 12.4.1, we elaborated on anonymizing HTTP proxy servers and their ability to process nested URLs. It is important to note at this point that not all parts of a nested URL must be unencrypted. In fact, it is possible to encrypt parts of a nested URL in a way that they can be decryted by the anonymizing HTTP proxy server that processes the nested URL. For example, imagine what happens if the document part in http:// proxy.../http://www.esecurity.ch would be encrypted. In this case, the document part would look like random data and the resulting nested URL would look like http://proxy.../url_encrypted/rez73529j63... In this example, the prefix url_encrypted indicates that the string that follows (i.e., rez73529j63... ) actually refers to an encrypted URL. The anonymizing HTTP proxy server (serving the request) would then take the appropriate cryptographic key to decrypt the relavant parts of the encrypted URL and retrieve the corresponding resource from the Web server, accordingly. In our example, the anonymizing HTTP proxy server would decrypt rez73529j63... and retrieve the requested resource from http://www.esecurity.ch. If the resource contained some URLs, these URLs would also have to be encrypted before the response is returned back to the browser. Obviously, URL rewriting techniques can be used at this point.

Note that URL decryption must only be possible for the anonymizing HTTP proxy server, whereas URL encryption needs to be possible for everybody. Consequently, URL encryption and decryption look like a suitable application for public key cryptography. ^[25] Consequently, the Rewebber service holds an RSA public key pair that is used to encrypt and decrypt URLs. The public key is published and documented, for example, in the Rewebber service s FAQ document.

In some literature, anonymizing HTTP proxy servers holding a public key pair that can also be used to transparently encrypt and decrypt URLs are also called rewebbers. Similarly, the encrypted parts of URLs are called locators. These terms are also used in the remaining part of this chapter.

In summary, rewebbers (like, for example, the one provided by the Rewebber service) provide a simple but efficient way to provide support for anonymous publishing on the Web. There are, however, at least three limitations and shortcomings that should be kept in mind when one considers the use of this technology:

A rewebber provider must be trusted not to reveal unencryted or decrypted URLs.
Web publishers must make available and somehow publish encrypted URLs (i.e., URLs that are encrypted with the public key of the Rewebber service).
Users must enter encrypted URLs. These limitations and shortcomings are addressed in a more sophisticated technology that is overviewed and briefly discussed next .

12.5.2 TAZ servers and the rewebber network

Two researchers at the University of California at Berkeley generalized the use of rewebbers and developed a technology that employs rewebber chains in a so-called rewebber network and a mechanism to resolve logical names of resources into encrypted URLs to anonymously publish on the Web [16].

Let us assume that there is a rewebber network (i.e., a network consisting of rewebbers), and that the public keys of the rewebbers are publicly available in some certified form. Let s further assume that ”in order to make traffic analysis more difficult ”the rewebbers transparently encrypt and decrypt files using a secret key cryptosystem. In the prototype implementation, a DES version called DESX ^[26] is used.

If a Web publisher wants to anonymously publish a resource (e.g., an HTML file) on the Web, he or she randomly selects a chain of rewebbers R ₁ ; R ₂ ; . . . ; R _n leading from the browser to the Web server that holds and makes available the file, as well as a set of n DESX keys. He or she then uses the DESX keys and the rewebbers public keys to constructs a nested URL. Formally speaking, the nested URLs may look as follows:

http : // R ₁ /{ K _R1 , http : // R ₂ / { K _R2 , . . . http : // R _n / { K _Rn , URL } k _Rn . . .} k _R2 } k _R1 (12.2)

In this formula, each R _i (1 ‰ i ‰ n ) refers to a rewebber. According to the last layer, the nested URL is sent to the first rewebber (i.e., R ₁ ). This rewebber uses its private key (i.e., k ^-1 _R1 ) to decrypt { K _R1 , http : // R ₂ / { K _R2 , . . . http : // R _n / { K _Rn , URL } k _Rn . . . } k _R2 } and the result is split into two parts.

The first part (i.e., K _R1 ) is stored to later decrypt any data that is sent back from the Web server.
The second part (i.e., http : // R ₂ = { K _R2 , . . . http : // R _n / { K _Rn , URL } k _Rn . . . } k _R2 ) is sent to the next rewebber in the chain (i.e., R ₂ ).

Similar to R ₁ , R ₂ decrypts the message with its private key (i.e., k ^-1 _R2 ) and splits the result into two parts. The first part (i.e., K _R2 ) is stored to later decrypt any data that is sent back from the Web server, and the second part is sent to the next rewebber in the chain. This continues until R _n finally decrypts K _Rn and URL . Once more, K _Rn is stored to later decrypt any data that is sent back from the Web server, and the resource referenced with URL is retrieved from this Web server. On the reverse path from the Web server back to the requesting browser, the multiple-encrypted resource is decrypted with each K _Ri (1 ‰ i ‰ n ) by the corresponding rewebber.

Rewebber chains and networks have the advantage that they don t make it necessary that there be a single rewebber that is ultimatively trusted. Instead, in a rewebber chain only the rewebber closest to the browser ever sees the decrypted data, and only the rewebber closest to the server knows from where it is really getting data. In order to link the two, the cooperation of every rewebber in the chain would be necessary. This avoids the existence of a single point of failure, and allows the distribution of trust throughout a network.

Since a rewebber network makes heavy use of URL encryption and locators, the above-mentioned problems of how to publish encrypted URLs and how to make users type them in correctly occur immediately. One possible solution to these problems is the creation of a logical namespace combined with a mechanism to automatically resolve a logical name into an encrypted URL. The resolution mechanisms can be implemented by special servers. In [16], the logical namespace is represented by a new top level domain .taz (TAZ standing for ˜ ˜temporary autonomous zone ) and the servers are called TAZ servers. Consequently, the function of a TAZ server is to offer publishers an easy way to point potential readers to their material, as well as offering readers an easy way to access it. A TAZ server consists essentially of a public database mapping virtual hostnames ending in .taz to locators for rewebbers. The emphasis on public is to stress that nothing in this database must be kept secret. Unlike an anonymous remailer like anon.penet.fi (which associates an alias e-mail address with a real one), TAZ servers merely associate .taz addresses with locators. Most importantly, the TAZ server administrator cannot decrypt the locators that are stored in the database. These facts are essential to building trust.

12.5.3 Publius

More recently, a group of researchers from AT&T Research and New York University designed and developed a ˜ ˜robust, tamper-evident and censorship-resistant Web publishing system named Publius ^[27] [17].

In short, the Publius system consists of Web publishers (people who want to anonymously publish static content ^[28] on the Web), Web servers that host random-looking content, and retrievers who browse the Publius system. There is a static, system-wide list of available servers.

Any content published with the Publius system is encrypted by the publisher and spread over some Web servers. More specifically , the publisher randomly chooses a key K from a secret key cryptosystem and encrypts the content with this key. In addition, he or she splits the key K into n shares, such that any k of them can reproduce the original key K , but k 1 give no hints as to the key. There are cryptographic schemes known as secret-sharing schemes that can be used for this purpose (e.g., [18]). Each selected Web server then receives the encrypted Publius content and one of the shares. At this point, the server has no idea what it is hosting; it simply stores some random looking data. To browse content, a retriever must get the encrypted Publius content from some server and k of the shares. This retrieval step is also supported by the Publius system in a way that is transparent to the user. More information about the system is available at http://cs1.cs.nyu.edu/~waldman/publius.html.

^[24] The service is currently available at www.rewebber.com.

^[25] Note, however, that URL encryption need not be possible for everybody. One could also think about a system in which URLs are sent over an SSL/TLS connection to a server that dynamically encrypts them. In this case, URL encryption and decryption could also be implemented with secret key cryptography.

^[26] The DESX encryption algorithm refers to a technique intended to extend the strength of DES that was originally proposed by Ronald L. Rivest.

^[27] Publius was the pen name used by the authors of the Federalist Papers, Alexander Hamilton, John Jay, and James Madison. This collection of 85 articles, published pseudonymously in New York State newspapers form October 1787 through May 1788, was influential in convincing New York voters to ratify the proposed United States constitution.

^[28] In its current form, the Publius system does not provide support for dynamicaly created content.