Traffic analysis

From Citizendium
Jump to navigation Jump to search
This article is a stub and thus not approved.
Main Article
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
This editable Main Article is under development and subject to a disclaimer.
This article is about Traffic analysis. For other uses of the term Analysis , please see Analysis (disambiguation).

Traffic analysis is a kind of signals intelligence. Analysts can derive conclusions about encrypted signals, through traffic analysis, even when they can't decrypt them. Analysts can derive conclusions from the signal's length, when they were broadcast, and whether other stations they were monitoring seemed to respond to the original signal.

Good analysts can sometimes deduce useful intelligence from patterns of message traffic, without breaking codes or reading the messages. In one case during World War II, the British guessed an attack was coming because all German radio traffic stopped. The "radio silence" order, intended to preserve security, actually gave the game away.

In general, traffic analysis by itself is not very useful. However, in the context of a larger intelligence effort where quite a bit is already known, it can be very useful. When you are solving a complex puzzle, every little bit helps.

Even just knowing that there is network traffic between two sites may tell an analyst something useful, especially when combined with whatever other information he or she may have. In an industrial espionage situation, one might deduce something interesting just by knowing that packets were passing between company A and company B, especially if one were able to tell which departments were involved, or if one already knew that A was looking for acquisitions and B was seeking funds for expansion. It is more interesting if you can tell it is email, and perhaps yet more if you know the sender and recipient.

Is your CEO exchanging email with a venture capital firm? With bankruptcy trustees? With an executive recruiting agency? With the holder of some important patents? If an eavesdropper learns about any of those, then he has interesting intelligence on your company, whether or not he can read the messages themselves.

A variant of traffic analysis involves mapping out communication networks. For example, given one suspect in an organised crime or terrorism group, you might look at all his or her Facebook friends or Twitter followers, or everyone he or she contacts by phone or email, then look at their contacts and so on. Eventually, you might uncover a whole network and even work out who were the key players.

Except in the simplest cases, traffic analysis is hard to do well. It requires both considerable resources and considerable analytic skill. However, intelligence agencies of various nations have been doing it for centuries and many of them are likely quite good at it by now. Various commercial organisations, especially those working on "targeted marketing", may also be quite good at analysing certain types of traffic.

In general, defending against traffic analysis is also difficult. Inventing a really good defense could get you a PhD and some interesting job offers.

Resisting traffic analysis on networks

Encrypting network protocols such as IPsec, SSH and SSL are not designed to resist traffic analysis and there are no simple ways to extend them to do so. That said, there are ways to make traffic analysis harder. This section describes them.

One might choose to use encryption even where it appears unnecessary in order to make analysis more difficult. Consider two offices which pass a small volume of business data between them using IPsec and also transfer large volumes of Usenet news. At first glance, it would seem silly to encrypt the newsfeed, except possibly for any newsgroups that are internal to the company. Why encrypt data that is all publicly available from many sites?

However, if we encrypt a lot of news and send it down the same connection as our business data, we make traffic analysis much harder. A snoop cannot now make inferences based on patterns in the volume, direction, sizes, sender, destination, or timing of our business messages. Those messages are hidden in a mass of news messages encapsulated in the same way.

If we're going to do this we need to ensure that keys change often enough to remain secure even with high volumes and with the adversary able to get plaintext of much of the data. We also need to look at other attacks this might open up. For example, can the adversary use a chosen plaintext attack, deliberately posting news articles which, when we receive and encrypt them, will help break our encryption? Or can he block our business data transmission by flooding us with silly news articles? Or ...

Also, note that this does not provide complete protection against traffic analysis. A clever adversary might still deduce useful intelligence from statistical analysis (perhaps comparing the input newsfeed to encrypted output, or comparing the streams we send to different branch offices), or by looking for small packets which might indicate establishment of TCP connections, or ...

As a general rule, though, to improve resistance to traffic analysis, you should encrypt as much traffic as possible, not just as much as seems necessary.

This also applies to using multiple layers of encryption. If you have an IPsec tunnel between two branch offices, it might appear silly to send PGP-encrypted email through that tunnel. However, if you suspect someone is snooping your traffic, then it does make sense. First, it protects the mail headers; they cannot even see who is mailing who. Second, it protects against user bungles or software malfunctions that accidentally send messages in the clear. Finally, it makes any attack on the mail encryption much harder; they have to break IPsec or break into your network before they can start on the mail encryption.

Similar arguments apply for SSL-encrypted web traffic or SSH-encrypted remote login sessions, even for end-to-end IPsec tunnels between systems in the two offices.