Schneier on Security

Clive Robinson • March 25, 2011 11:49 AM

It needs to be said that TOR should come with a big health warning.

The reason being it is a ‘low latency’ ‘demand oriented’ network.

These two failings considerably reduce it’s security value for a number of reasons.

As such the best TOR offers in reality is a limited degree of privacy on ‘data in transit’ within the TOR network.

For instance it is quite susceptable to active traffic flow attacks one of which is to add “jitter” to packets prior to them entering the TOR network.

That is an attacker who can control or influence a node between the user and the point of entry they use to the TOR network can from that point on track the packet stream at other places they have access be it in the TOR internal path or after the packet has left the TOR network for the service the user is connecting to.

Sadly for many users the TOR network is actually not very well distributed due to the nature of the Internet the TOR network actualy has just a few major nodes where trans-national or trans-organisational choke points exist.

To insert network jitter onto either a user or service traffic often all it requires is the ability to inject packets into the network node from a higher bandwidth connection (ie a limited DoS attack). This jitter remains on the traffic in many cases untill it reaches it’s destination. It can be seen by using a simple autocorrelation function on the edge timing of packets which “lifts from the noise” the jitter signal, thus fingering the packet stream.

However TOR does not always provide even privacy, If I can see or identify a users traffic at a service often it is unencrypted and thus visable to simple monitoring. Even if it is encrypted into the service if the service is public and the data is static then often it is possible to identify the data sent simply by the file size and rate monitoring.

Whilst these faults can be corrected (rate limiting, adding random jitter between nodes, stream packet stuffing, out of order transmission and data stuffing) it appears that the TOR developers are not keen to do these things.

Untill such time as they become available I could not say I would trust TOR to give anything other than the illusion of privacy for the average user.

Clive Robinson • March 26, 2011 7:28 AM

@ Magetoo,

“… pretty well known in the past for being slow, anything that adds latency or uses more bandwidth is not going to be too popular with the main developers”

And this is the crux of the issue.

As I have said many times befor “security-v-efficiency” as a general rule every time you make something more efficient unless you take special measures you make it less secure.

It is clear that the Tor developers are not taking the special measures required.

One of the things you hear about TEMPEST/EmSec is “clock the inputs and clock the outputs”.

This helps remove a lot of the “timing side channels” that can be used to exploit Tor and strip of even it’s meager privacy.

Taking it further is “channel saturation” if a “point to point” communications channel is always at full capacity it provides little information to a potential eves dropper. There are a number of ways this can be achieved the first major way is by “rate limiting” the second is by “traffic stuffing” or a combination of both.

When you have a very variable rate of traffic flow this is a “bandwidth to signal” issue which can on some networks be costly. There are two basic solutions to this. The first is to use “store and forward” where by traffic is stored in a node and then sent in one “burst” of fixed size/duration. The second solution is multiple sub channels of fixed bandwidth along any given signal path.

In either case you have to be very carefull how you arange the expansion and contraction of used bandwidth otherwise you open up secondary side channels that can be exploited, especialy where you have no control on the amount of traffic entering a node (such as on a public access system like Tor).

Another solution to the rate limiting issue is “traffic diversion”. If a node has several “point to point” links it can put excess traffic from one link out onto another link and alow it to be delivered via a “diversion”. If the basic network is configured as a mesh to alow this then potentialy packets can not only arive at their destination very out of order they can be very late as well. Such systems also alow a high end adversary to force traffic diversion through favourd nodes to their advantage so it is a very very complex issue to manage over and above the difficulties of ordinary routing issues.

Most of the issues with Tor as you note boil down to “latency” issues of “interactive traffic” the desire to minimise this is the real issue where the seccurity of the network breaks down.

But simply the lower the latency the higher the bandwidth of the side channels by which the traffic flow can be used. This also means the faster an attacker can “nail you cold”.

It is because of this “design choice” you will not find me using Tor nor could I possibly recomend it because it also “attracts attention” just by it’s use and the effective trade off is not in a users favour at all.

Which brings me around to your comment,

“Their main goal seems to be to make things reasonably anonymous for ordinary humans and easy to use, not strong guarantees for the most security-aware .0001% of the population”

Anonymity is as the old joke has it “like virginity” it is something you have or you have lost for ever and all it takes is one p**k to lose it (as is the point made by this paper).

Anything less than 100% anonymity is just a variation of “security by obscurity” and as we are finding with modern methods it is not possible to make anything of usefulness anonymous against a well resourced attacker.

We have seen with US, UK, European, et al legislation that all traffic flow information is to be kept effectivly indefinatly. Thus the statistical time channel methods can be applied at any time in the future against “single channel” “low latency” traffic”. And as Bruce often points out “Attacks only improve with time”. Therefore the anonymity that Tor currently offers is dead and buried, get over it and move on to other more diverse security methods.

So a warning for those using Tor for activities that are either “illegal” or seen as “reprehensible” in your jurisdiction. You have already “commited the crime” and you have left your “DNA at the crime scene”, it is now only a question of time and priorities before you get a “midnight knock” on the door…

If you must carry out these activities go and use some network you are not associated with and then only once…

That is the future for “anonymity” lies initialy in “random unatributable access”, then not in “low latency” networks but in multiple node “store and forward” networks with “decoupled entities” responsible for moving traffic from store to multiple store. However this raises a whole host of data managment issues that will prove as in the ancient Chinese curse “interesting”.

Whic brings me around to your,

“Of course this involves trade-offs. It seems to me that deciding exactly what trade-offs to make would be the hard problem here; not designing the perfect system on paper, but getting people to actually use it.”

The most important trade off is “low latency” it is extrodinarily difficult to achive whilst even having some semblance of “anonymity”. Tor as it is currently configured realy is not capable of delivering both low latency and anonymity currently.

Changes that need to be made is to firstly have multiple routes for data to be fragmented and fired “shotgun” like to achieve a wide spread across the whole network. This needs to be coupled with store and forward techniques to break down the ability to cross correlate packets to individual user or service data streams. Data also needs to be duplicated and sent to different nodes where most will silently die to /dev/null. Node to node routes need to fully occupie rate limited channels using traffic diversion as required or opening other channels to other nodes as required to offload traffic. A minimum of 20% of the traffic originating from a node in any one channel needs to be fake that will hope on two or three other nodes before dropping to /dev/null. All channels that are opened need to be kept open for a traffic period exceading twice the maximum traffic size (that is if the largest message sent down the channel is 1Mb the channel should be kept open for atleast another 1Mb of null traffic before closing).

But the most important change users should make is to get used to using “store and forward” systems.

Back in the early days of the Internet it was quite common to use the likes of Email to get files from FTP sites via an intermediary agent. The process could usefully be recreated in a much more secure form for the likes of P2P networks and Bitorrent.

Put simply, a user would,

1, Use one of a number of directory services to find out which FTP sites held the file they wished to get.

2, The user would then send a request Email to one of several intermediary agent services, with the chosen FTP site and path to the file.

3, The agent service would then get the file from the users chosen FTP site and wrap it up as an ASCII armored message.

4, The agent service would then send the message in smallish chunks to the users Email account.

5, The user would log into their EMail account some hours or days later to retrieve all the chunks.

6, The user would then use a script to rebuild the chunks back into the original file.

It can be fairly easily seen how a modifed version of this using multiple “blind servers” and “blind agents” through multiple nodes could render any usefull time based traffic analysis mute.

Clive Robinson • March 27, 2011 7:41 AM

@ Nick P,

I’ve had a quick look through the thesis and yes it looks interesting 8)

However he missed covering one bet, in the section “other channels” he missed the oportunity to mention such things as “soft fonts” which can have a major effect on “compromising emanations”.

I shall take a little time after cooking Sunday lunch to print it out and read through it more carefully (whilst others scrub the pots pans and dishes 8)