Traffic analysis

From Infogalactic: the planetary knowledge core
(Redirected from Traffic flow security)
Jump to: navigation, search

<templatestyles src="Module:Hatnote/styles.css"></templatestyles>

Traffic analysis is the process of intercepting and examining messages in order to deduce information from patterns in communication. It can be performed even when the messages are encrypted and cannot be decrypted. In general, the greater the number of messages observed, or even intercepted and stored, the more can be inferred from the traffic. Traffic analysis can be performed in the context of military intelligence, counter-intelligence, or pattern-of-life analysis, and is a concern in computer security.

Traffic analysis tasks may be supported by dedicated computer software programs. Advanced traffic analysis techniques may include various forms of social network analysis.

In military intelligence

In a military context, traffic analysis is a basic part of signals intelligence, and can be a source of information about the intentions and actions of the enemy. Representative patterns include:

  • Frequent communications — can denote planning
  • Rapid, short communications — can denote negotiations
  • A lack of communication — can indicate a lack of activity, or completion of a finalized plan
  • Frequent communication to specific stations from a central station — can highlight the chain of command
  • Who talks to whom — can indicate which stations are 'in charge' or the 'control station' of a particular network. This further implies something about the personnel associated with each station
  • Who talks when — can indicate which stations are active in connection with events, which implies something about the information being passed and perhaps something about the personnel/access of those associated with some stations
  • Who changes from station to station, or medium to medium — can indicate movement, fear of interception

There is a close relationship between traffic analysis and cryptanalysis (commonly called codebreaking). Callsigns and addresses are frequently encrypted, requiring assistance in identifying them. Traffic volume can often be a sign of an addressee's importance, giving hints to pending objectives or movements to cryptanalysts.

Traffic flow security

Traffic-flow security is the use of measures that conceal the presence and properties of valid messages on a network to prevent traffic analysis. This can be done by operational procedures or by the protection resulting from features inherent in some cryptographic equipment. Techniques used include:

  • changing radio callsigns frequently
  • encryption of a message's sending and receiving addresses (codress messages)
  • causing the circuit to appear busy at all times or much of the time by sending dummy traffic
  • sending a continuous encrypted signal, whether or not traffic is being transmitted. This is also called masking or link encryption.

Traffic-flow security is one aspect of communications security.

COMINT metadata analysis

Lua error in package.lua at line 80: module 'strict' not found. Lua error in package.lua at line 80: module 'strict' not found. The Communications' Metadata Intelligence, or COMINT metadata is a term in communications intelligence (COMINT) referring to the concept of producing intelligence by analyzing only the technical metadata, hence, is a great practical example for traffic analysis in intelligence.

While traditionally information gathering in COMINT is derived from intercepting transmissions, tapping the target's communications and monitoring the content of conversations, the metadata intelligence is not based on content but on technical communicational data.

Non-content COMINT is usually used to deduce information about the user of a certain transmitter, such as locations, contacts, activity volume, routine and its exceptions.

Examples

For example, if a certain emitter is known as the radio transmitter of a certain unit, and by using direction finding (DF) tools, the position of the emitter is locatable; hence the changes of locations can be monitored. That way we're able to understand that this certain unit is moving from one point to another, without listening to any orders or reports. If we know that this unit reports back to a command on a certain pattern, and we know that another unit reports on the same pattern to the same command, then the two units are probably related, and that conclusion is based on the metadata of the two units' transmissions, and not on the content of their transmissions.

Using all, or as much of the metadata available is commonly used to build up an Electronic Order of Battle (EOB) – mapping different entities in the battlefield and their connections. Of course the EOB could be built by tapping all the conversations and trying to understand which unit is where, but using the metadata with an automatic analysis tool enables a much faster and accurate EOB build-up that alongside tapping builds a much better and complete picture.

World War I

  • British analysts in World War I noticed that the call sign of German Vice Admiral Reinhard Scheer, commanding the hostile fleet, had been transferred to a land-based station. Admiral of the Fleet Beatty, ignorant of Scheer's practice of changing callsigns upon leaving harbor, dismissed its importance and disregarded Room 40 analysts' attempts to make the point. The German fleet sortied, and the British were late in meeting them at the Battle of Jutland.[1] If traffic analysis had been taken more seriously, the British might have done better than a 'draw'.[original research?]
  • French military intelligence, shaped by Kerckhoffs's legacy, had erected a network of intercept stations at the Western front in pre-war times. When the Germans crossed the frontier the French worked out crude means for direction-finding based on intercepted signal intensity. Recording of call-signs and volume of traffic further enabled them to identify German combat groups and to distinguish between fast-moving cavalry and slower infantry.[1]

World War II

  • In early World War II, the aircraft carrier HMS Glorious was evacuating pilots and planes from Norway. Traffic analysis produced indications Scharnhorst and Gneisenau were moving into the North Sea, but the Admiralty dismissed the report as unproven. The captain of Glorious did not keep sufficient lookout, and was subsequently surprised and sunk. Harry Hinsley, the young Bletchley Park liaison to the Admiralty, later said his reports from the traffic analysts were taken much more seriously thereafter.[2]
  • During the planning and rehearsal for the attack on Pearl Harbor, very little traffic passed by radio, subject to interception. The ships, units, and commands involved were all in Japan and in touch by phone, courier, signal lamp, or even flag. None of that traffic was intercepted, and could not be analyzed.[1]
  • The espionage effort against Pearl Harbor before December didn't send an unusual number of messages; Japanese vessels regularly called in Hawaii and messages were carried aboard by consular personnel. At least one such vessel carried some Japanese Navy Intelligence officers. Such messages cannot be analyzed. It has been suggested,[3] however, the volume of diplomatic traffic to and from certain consular stations might have indicated places of interest to Japan, which might thus have suggested locations to concentrate traffic analysis and decryption efforts.[citation needed]
  • Admiral Nagumo's Pearl Harbor Attack Force sailed under radio silence, with its radios physically locked down. It is unclear if this deceived the U.S.; Pacific Fleet intelligence was unable to locate the Japanese carriers in the days immediately preceding the attack on Pearl Harbor (Kahn).
  • The Japanese Navy played radio games to inhibit traffic analysis (see Examples, below) with the attack force after it sailed in late November. Radio operators normally assigned to carriers, with a characteristic Morse Code "fist", transmitted from inland Japanese waters, suggesting the carriers were still near Japan (Kahn)[4]
  • Operation Quicksilver, part of the British deception plan for the Invasion of Normandy in World War II, fed German intelligence a combination of true and false information about troop deployments in Britain, causing the Germans to deduce an order of battle which suggested an invasion at the Pas-de-Calais instead of Normandy. The fictitious divisions created for this deception were supplied with real radio units, which maintained a flow of messages consistent with the deception.[5] p. 233

In computer security

Traffic analysis is also a concern in computer security. An attacker can gain important information by monitoring the frequency and timing of network packets. A timing attack on the SSH protocol can use timing information to deduce information about passwords since, during interactive session, SSH transmits each keystroke as a message.[6] The time between keystroke messages can be studied using hidden Markov models. Song, et al. claim that it can recover the password fifty times faster than a brute force attack.

Onion routing systems are used to gain anonymity. Traffic analysis can be used to attack anonymous communication systems like the Tor anonymity network. Adam Back, Ulf Möeller and Anton Stiglic present traffic analysis attacks against anonymity providing systems .[7] Steven J. Murdoch and George Danezis from University of Cambridge presented [8] research showing that traffic-analysis allows adversaries to infer which nodes relay the anonymous streams. This reduces the anonymity provided by Tor. They have shown that otherwise unrelated streams can be linked back to the same initiator.

Remailer systems can also be attacked via traffic analysis. If a message is observed going to a remailing server, and an identical-length (if now anonymized) message is seen exiting the server soon after, a traffic analyst may be able to (automatically) connect the sender with the ultimate receiver. Variations of remailer operations exist that can make traffic analysis less effective.

Countermeasures

It is difficult to defeat traffic analysis without both encrypting messages and masking the channel. When no actual messages are being sent, the channel can be masked [9] by sending dummy traffic, similar to the encrypted traffic, thereby keeping bandwidth usage constant .[10] "It is very hard to hide information about the size or timing of messages. The known solutions require Alice to send a continuous stream of messages at the maximum bandwidth she will ever use...This might be acceptable for military applications, but it is not for most civilian applications." The military-versus-civilian problems applies in situations where the user is charged for the volume of information sent.

Even for Internet access, where there is not a per-packet charge, ISPs make statistical assumption that connections from user sites will not be busy 100% of the time. The user cannot simply increase the bandwidth of the link, since masking would fill that as well. If masking, which often can be built into end-to-end encryptors, becomes common practice, ISPs will have to change their traffic assumptions.

See also

References

  1. 1.0 1.1 1.2 Lua error in package.lua at line 80: module 'strict' not found.
  2. Lua error in package.lua at line 80: module 'strict' not found.
  3. Lua error in package.lua at line 80: module 'strict' not found.
  4. Lua error in package.lua at line 80: module 'strict' not found.
  5. Lua error in package.lua at line 80: module 'strict' not found.
  6. Lua error in package.lua at line 80: module 'strict' not found.
  7. Lua error in package.lua at line 80: module 'strict' not found.
  8. Lua error in package.lua at line 80: module 'strict' not found.
  9. Lua error in package.lua at line 80: module 'strict' not found.
  10. Lua error in package.lua at line 80: module 'strict' not found.

Further reading