[tor-dev] New Paper: Cloud-based Onion Routing

[Nick Jones]

On Wednesday, July 13, 2011 at 4:58 PM, Aaron wrote:

> I have a few questions
> 
> Q1: Regarding network bootstrap protocol: Consider the scenario where
> a censor mines the boostrap node list and blocks these nodes. Do you
> implement any mechanisms to prevent a censor from obtaining the entire
> set of bootstrap nodes? Similarly, aren't public directory servers
> also vulnerable to censorship?
> 

Currently, we don't have any major protection from enumerating the list of bootstrapping nodes.
It is definitely a problem we are aware of, and we're thinking about possible ways to protect 
them. In our design, we only give out one bootstrapping node at a time, with the hope that this 
makes enumerating them somewhat more difficult. Additionally, if we can detect that a 
bootstrapping node has been blocked, we can use the elasticity of cloud hosting to move it to a 
new IP or a new cloud. Admittedly, this may devolve into a cat and mouse game of moving the 
bootstrapping nodes around. 

Similarly, since you learn about the bootstrapping nodes through the directories, the directories
have many of the same problems and solutions. If the directories stay at a static IP/DNS name, 
then they will be blocked quickly. However, if the user still has a cached valid directory from the 
last time he was connected to COR, he could build a circuit and then retrieve an updated directory,
assuming at least some of the nodes from the last directory retrieval were still active. We can 
move the directories around within the cloud, but then you need a "directory of directories", and 
that gets messy. 

Admittedly, our system doesn't fundamentally solve the bootstrapping problem (of new users 
gaining access), but we hope that it makes it more difficult for existing users to be blocked.

> Q2: Regarding token redemption: Does an ASP relay contact the ASP
> token bank through COR? Could the token verification history be used
> to reveal which paths were constructed?
> 

The ASP relay contacts the ASP token bank directly. If multiple malicious ASPs colluded, they 
might use token redemption timing analysis to figure out the circuit's path. However, this isn't really 
any different than normal timing attacks. The tokens themselves can't be traced back to the user in
any way. You need to use multiple ASPs to be protected, much like you need to use relays in Tor from
multiple ISPs.

> --Aaron
> 
> On Wed, Jul 13, 2011 at 11:47 AM, Nick Jones <najones at cs.princeton.edu (mailto:najones at cs.princeton.edu)> wrote:
> > Hi All,
> > 
> > I'm a graduate student at Princeton, and our research group has recently submitted a paper proposing a design for cloud based onion routing. The goal of our research is to securely perform onion routing on cloud based infrastructure (like Amazon EC2 and Rackspace) while allowing users to retain the same (or almost the same) privacy as when using Tor. We distribute trust across multiple cloud providers, and use Chaum's e-cash for payment and access control. Additionally, we hope that the elasticity of cloud infrastructure will make cloud based OR more censorship resistant than current systems.
> > 
> > This project is still in a relatively early stage, and we would love to get feedback from the Tor community. We would welcome any comments/questions/criticisms.
> > 
> > 
> > 
> > Our project's website is available at:
> > 
> > http://sns.cs.princeton.edu/projects/cor/
> > 
> > 
> > A direct link to our paper is here:
> > 
> > http://www.cs.princeton.edu/~najones/publications/cor-foci11.pdf
> > 
> > 
> > Our abstract:
> > 
> > Internet censorship and surveillance have made anonymity tools increasingly critical for free and open Internet access. Tor, and its associated ecosystem of vol- unteer traffic relays, provides one of the most secure and widely-available means for achieving Internet anonymity today. Unfortunately, Tor has limitations, including poor performance, inadequate capacity, and a susceptibility to wholesale blocking. Rather than utilizing a large number of volunteers (as Tor does), we propose mov- ing onion-routing services to the “cloud” to leverage the large capacities, robust connectivity, and economies of scale inherent to commercial datacenters. This paper de- scribes Cloud-based Onion Routing (COR), which builds onion-routed tunnels over multiple anonymity service providers and through multiple cloud hosting providers, dividing trust while forcing censors to incur large collat- eral damage. We discuss the new security policies and mechanisms needed for such a provider-based ecosys- tem, and present some preliminary benchmarks. At to- day’s prices, a user could gain fast, anonymous network access through COR for only pennies per day.
> > 
> > 
> > Thanks!
> > 
> > Nick Jones
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev at lists.torproject.org (mailto:tor-dev at lists.torproject.org)
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org (mailto:tor-dev at lists.torproject.org)
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


Hopefully that answers your questions. If anything isn't clear, please let me know. We 
appreciate and welcome the feedback.

Thanks,

Nick Jones