The exploit involved the very powerful (500KW) Aspidistra transmitter, coupled to a directional antenna farm. With that power, they could make it sound like a local station in the target area.

With a staff of fake announcers, a fake German band, and recordings of recent speeches from high-ranking Nazis, they would smoothly switch from merely relaying the German network to emulating it with their own staff. They could then make modifications to news broadcasts, occasionally creating panic and confusion.

German transmitters were switched off during air raids, to prevent them from being used as navigational aids for bombers. But many were connected into a network and broadcast the same content. When a targeted transmitter switched off, Aspidistra began transmitting on their original frequency, initially retransmitting the German network broadcast as received from a still-active station. As a deception, false content and pro-Allied propaganda would be inserted into the broadcast. The first such "intrusion" was carried out on March 25, 1945, as shown in the operations order at the right.

On March 30, 1945, "Aspidistra" intruded into the Berlin and Hamburg frequencies warning that the Allies were trying to spread confusion by sending false telephone messages from occupied towns to unoccupied towns. On April 8, 1945, "Aspidistra" intruded into the Hamburg and Leipzig channels to warn of forged banknotes in circulation. On April 9, 1945, there were announcements encouraging people to evacuate to seven bomb-free zones in central and southern Germany. All these announcements were false.

The German radio network tried announcing "The enemy is broadcasting counterfeit instructions on our frequencies. Do not be misled by them. Here is an official announcement of the Reich authority." The Aspidistra station made similar announcements, to cause confusion and make the official messages ineffective.

...doctored photographs are the least of our worries. If you want to trick someone with a photograph, there are lots of easy ways to do it. You don't need Photoshop. You don't need sophisticated digital photo-manipulation. You don't need a computer. All you need to do is change the caption.

The photographs presented by Colin Powell at the United Nations in 2003 provide several examples. Photographs that were used to justify a war. And yet, the actual photographs are low-res, muddy aerial surveillance photographs of buildings and vehicles on the ground in Iraq. I'm not an aerial intelligence expert. I could be looking at anything. It is the labels, the captions, and the surrounding text that turn the images from one thing into another. Photographs presented by Colin Powell at the United Nations in 2003.

Powell was arguing that the Iraqis were doing something wrong, knew they were doing something wrong, and were trying to cover their tracks. Later, it was revealed that the captions were wrong. There was no evidence of chemical weapons and no evidence of concealment. Morris's mockery of the sweeping interpretations made in Powell's photographs.

There is a larger point. I don't know what these buildings were really used for. I don't know whether they were used for chemical weapons at one time, and then transformed into something relatively innocuous, in order to hide the reality of what was going on from weapons inspectors. But I do know that the yellow captions influence how we see the pictures. "Chemical Munitions Bunker" is different from "Empty Warehouse" which is different from "International House of Pancakes." The image remains the same but we see it differently.

Change the yellow labels, change the caption and you change the meaning of the photographs. You don't need Photoshop. That's the disturbing part. Captions do the heavy lifting as far as deception is concerned. The pictures merely provide the window-dressing. The unending series of errors engendered by falsely captioned photographs are rarely remarked on.

One of his favorite OSS stories involved a colleague sent to occupied France to destroy a seemingly impenetrable German tank at a key crossroads. The French resistance found that grenades were no use.

The OSS man, fluent in German and dressed like a French peasant, walked up to the tank and yelled, "Mail!"

The lid opened, and in went two grenades.

Hall's book about his OSS days, You're Stepping on My Cloak and Dagger, is a must read.

The Wall Street Journal reported how this gambit played out in Colombia:

"The plan had a chance of working because, for months, in an operation one army officer likened to a 'broken telephone,' military intelligence had been able to convince Ms. Betancourt's captor, Gerardo Aguilar, a guerrilla known as 'Cesar,' that he was communicating with his top bosses in the guerrillas' seven-man secretariat. Army intelligence convinced top guerrilla leaders that they were talking to Cesar. In reality, both were talking to army intelligence."

In a man-in-the-middle attack, the attacker inserts himself between two communicating parties. Both believe they're talking to each other, and the attacker can delete or modify the communications at will. The Wall Street Journal reported how this gambit played out in Colombia.

This ploy worked because Cesar and his guerrilla bosses didn't know each other well. They didn't recognize each others' voices, and didn't have a friendship or shared history that could have tipped them off about the ruse. Man-in-the-middle is defeated by context, and the FARC guerillas didn't have any.

And that's why man-in-the-middle, abbreviated MITM in the computer security community, is such a problem online: Internet communication is often stripped of any context. There's no way to recognize someone's face. There's no way to recognize someone's voice. When you receive an e-mail purporting to come from a person or organization, you have no idea who actually sent it. When you visit a website, you have no idea if you're really visiting that website. We all like to pretend that we know who we're communicating with -- and for the most part, of course, there isn't any attacker inserting himself into our communications -- but in reality, we don't. And there are lots of hacker tools that exploit this unjustified trust, and implement MITM attacks.

Even with context, it's still possible for MITM to fool both sides -- because electronic communications are often intermittent. Imagine that one of the FARC guerillas became suspicious about who he was talking to. So he asks a question about their shared history as a test: "What did we have for dinner that time last year?" or something like that. On the telephone, the attacker wouldn't be able to answer quickly, so his ruse would be discovered. But e-mail conversation isn't synchronous. The attacker could simply pass that question through to the other end of the communications, and when he got the answer back, he would be able to reply.

This is the way MITM attacks work against web-based financial systems. A bank demands authentication from the user: a password, a one-time code from a token or whatever. The attacker sitting in the middle receives the request from the bank and passes it to the user. The user responds to the attacker, who passes that response to the bank. Now the bank assumes it is talking to the legitimate user, and the attacker is free to send transactions directly to the bank. This kind of attack completely bypasses any two-factor authentication mechanisms, and is becoming a more popular identity theft tactic.

There are cryptographic solutions to MITM attacks, and there are secure web protocols that implement them. Many of them require shared secrets, though, making them only useful in situations where people already know and trust each other.

The NSA-designed STU-III and STE secure telephones solve the MITM problem by embedding the identity of each phone together with its key. (The NSA creates all keys and is trusted by everyone, so this works.) When two phones talk to each other securely, they exchange keys and display the other phone's identity on a screen. Because the phone is in a secure location, the user now knows who he is talking to, and if the phone displays another organization -- as it would if there were a MITM attack in progress -- he should hang up.

Zfone, a secure VoIP system, protects against MITM attacks with a short authentication string. After two Zfone terminals exchange keys, both computers display a four-character string. The users are supposed to manually verify that both strings are the same -- "my screen says 5C19; what does yours say?" -- to ensure that the phones are communicating directly with each other and not with an MITM. The AT&T TSD-3600 worked similarly.

This sort of protection is embedded in SSL, although no one uses it. As it is normally used, SSL provides an encrypted communications link to whoever is at the other end: bank and phishing site, alike. And the better phishing sites create valid SSL connections, so as to more effectively fool users. But if the user wanted to, he could manually check the SSL certificate to see if it was issued to "National Bank of Trustworthiness" or "Two Guys With a Computer in Nigeria."

No one does, though, because you both have to remember and be willing to do the work. (The browsers could make this easier if they wanted to, but they don’t seem to want to.) In the real world, you can easily tell a branch of your bank from a money changer on a streetcorner. But on the internet, a phishing site can be easily made to look like your bank's legitimate website. Any method of telling the two apart takes work. And that's the first step to fooling you with a MITM attack.

Man-in-the-middle isn't new, and it doesn't have to be technological. But the internet makes the attacks easier and more powerful, and that's not going to change anytime soon.

---

Bruce Schneier is chief security technology officer of BT, and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World.

The first session, on deception, was fascinating. It emphasised the huge range of problems, from detecting deception in interpersonal contexts such as interrogation through the effects of context and misdirection to how we might provide better trust signals to computer users.

Over the past seven years, security economics has gone from nothing to a thriving research field with over 100 active researchers. Over the next seven I believe that security psychology should do at least as well. I hope I’ll find enough odd minutes to live blog this first workshop as it happens!

[Edited to add:] See comments for live blog posts on the sessions; Bruce Schneier is also blogging this event.

Blogger: Pete Lindstrom

Microsoft’s Security Development Lifecycle (SDL) is the main product of its Trustworthy Computing Initiative, launched from the now-famous Bill Gates memo in 2002. Six years into the initiative, Microsoft surely must be reaping the benefits of, for example, the well-publicized security training every developer went through.

So, how do we determine whether the SDL is working? Microsoft suggests that this is a simple exercise – simply compare the number of public vulnerabilities disclosed for products prior to SDL with similar products developed after SDL. The most recent case was comparing Windows XP SP2 to Vista vulnerabilities in the first year. The count is down and Microsoft provides a quick and easy example of the logical fallacy “post hoc ergo propter hoc” which in this case means “public perception is ripe for deception.”

The biggest problem with Microsoft’s assertion is simply that there are too many variables that are uncontrolled and could just as easily be making the difference. There are too many unknowns related to effort of independent researchers and focus on a specific Microsoft platform. At the very least, Microsoft has done an admirable job in making people feel more secure. (I happen to believe the SDL is working as well, but that belief is a matter of conjecture without strong evidence).

If Microsoft wants to use public vulnerability counts as the ultimate arbiter, it needs to create an environment where independent researchers are encouraged to find bugs. Creating a controlled bounty program for a limited time period would increase incentives and at least provide circumstantial evidence of SDL effectiveness. Interestingly, if the number of vuln counts was higher, it still wouldn’t mean SDL is ineffective,  but the framing of the conversation would be entirely different.

The plot thickens when Microsoft makes claims that spending more time and leveraging external resources are a part of SDL. Whether they are or not, there is a big difference between making programmers more secure developers and simply spending more money on a problem. You don’t really need SDL if the latter is more beneficial.

But if public vulnerability counts are not the answer, what should Microsoft be doing to demonstrate the effectiveness of its SDL? Well, it is much easier to determine causality by controlling for all other variables, and conducting a test of two groups – one with SDL training and one without. Comparing vulnerability creation rates per unit output (either developer-hours or lines of code, for example) would go a long way to answering the effectiveness question.

At this stage, it might be difficult to find a group of developers in-house that aren’t SDL trained, and Microsoft is fully vested in the program such that it wouldn’t allow an untrained developer on a real project, so a new experiment may need to be set up using some arbitrary project created solely for the experiment. Alternatively, Microsoft could measure the differences in development skills after an acquisition and during the transition to SDL-trained developers. Or a final option is to conduct a private benchmarking exercise where the effectiveness is compared among multiple groups.

At this stage, it may be even harder to figure out the effectiveness of an SDL-trained QA group. Presumably, QA training will help the group find more bugs earlier, but if the developers are getting better, then the rate of finding vulnerabilities will go down. There are techniques associated with defect density that could be leveraged to determine this effectiveness level as well.

Creating fewer bugs and finding more bugs early, I believe, are the real expectations of SDL, and finding those numbers would provide much stronger evidence for or against its effectiveness. Not only that, but this information would better frame discussions around ultimate effectiveness of software development: Microsoft is likely to have spent more money than anyone else on its SDL efforts, so the benchmarks provided by the company would serve as an upper limit for expectations.