Fair warning: If I give a talk --- at your conference, lecture series, meeting, whatever -- and you ask me for "a copy of my presentation" I'm probably going to refuse. It isn't personal and I'm not trying to be difficult. It's just that I have nothing that I can sensibly give you.

Many speakers these days make their visual aids available, but I don't. I don't always use any, but even when I do, they just aren't intended to be comprehensible outside the context of my talk. Creating slides that can serve double duty as props for my talk and as a stand-alone summary of the content is, I must confess, a talent that lies beyond the limits of my ability. Fortunately, when I give a talk I've usually also written something about the subject too, and almost all my papers are freely available to all. Unlike my slides, I try to write in a way that makes sense even without me standing there explaining things while you read.

"Presentation software" like PowerPoint (and KeyNote and others of that ilk) has blurred the line between mere visual aids and the presentations themselves. I've grown to loathe PowerPoint, not because of particular details that don't suit me (though it would be nice if it handled equations more cleanly), but because it gets things precisely backwards. When I give a talk, I want to be in control. But the software has other ideas.

PowerPoint isn't content to sit in the background and project the occasional chart, graph or bullet list. It wants to organize the talk, to manage the presentation. There's always going to be a slide up, whether you need it there or not. Want to skip over some material? OK, but only by letting the audience watch as you fast-forward awkwardly through the pre-set order. Change the order around to answer a question? Tough -- should have thought of that before you started. You are not the one in charge here, and don't you forget it.

When I give a talk, I like to rely on a range of tools -- my voice, hand gestures, props, live demos, and, yes, PowerPoint slides. I tend to mix and match. In other words, from PowerPoint's perspective, I'm usually using it badly, even abusively. I often ignore the slides for minutes on end, or digress on points only elliptically hinted at on the screen. When I really get going, the sides are by themselves useless or, worse, outright misleading. Distributing them separately would at best be an invitation to take them hopelessly and confusingly out of context, and at worst, a form of perjury.

Unfortunately, "PowerPoint" has become synonymous these days with "presentation", but I just don't work that way. Maybe you don't work that way either. There's no one-size-fits-all way to give a talk, or even a one-size-fits-me way. So when I'm asked for my slides, I must politely refuse and offer my papers as a substitute (an idea I owe to the great Edward Tufte).

Fortunately, I'm senior enough (or have a reputation for being cranky enough) that I can usually get away with refusing. Sometimes, though, when pressed hard, I'll give in and send these slides [pdf].


Addendum 26 November 2010: This post sure has struck a (perhaps dissonant) chord somewhere, especially for a long holiday weekend. I'm grateful to all who've emailed, blogged, and tweeted.

Several people have thoughtfully suggested their favorite alternatives to PowerPoint (Prezi seems to be the popular choice), which I'll certainly check out. And for the record, yes, I know about (and use when I can) PowerPoint's "presenter" mode, which improves control over the audience display. Unfortunately, both alternative software and presenter mode, while improvements, are at best unreliable, since they assume a particular configuration on the projecting computer. It often isn't possible to project from a personal laptop (especially in conferences run on tight schedules), leaving us at the mercy of whatever is at the podium. And that often means PowerPoint in single-screen mode.

In any case, while there is certainly room for me to improve my mastery of PowerPoint and its alternatives, this wouldn't solve the basic problem, which is that, in my case at least, my slides -- when I use them at all -- aren't the content. They won't help you understand things much more than would any of the other stuff I also happen to bring up on stage with me, like, say, my shoes (which you can't have, either). But you're welcome to my papers.

I'll be the first witness at this morning's (6/24/10) House Judiciary Committee hearing on ECPA Reform and the Revolution in Location-Based Technology, which, for DC locals, will start at 10am in room 2233 of the Rayburn building.

My testimony [pdf] will focus on the technical: how modern cell phones and wireless services calculate location, and how accurately they can track and record users' positions and movements. This is all in the context of surveillance: when the government gets a pen register order against a cell phone, for example, what information do (or should) they get about the target's location and movements compared with other kinds of tracking technology?

Other witnesses will include (among others) a special agent (from the Tennessee Bureau of Investigation) who does electronic surveillance, and a federal magistrate judge who has to sort out the legal issues when the government requests tracking information about a suspect. The hearing promises to be an interesting glimpse into how location tracking actually works in criminal investigations.

No idea if the hearing will be shown via a webcast or C-SPAN coverage.

Update 6/28/10: The hearing was interesting, and I especially enjoyed Chairman Nadler's line of questions to me about how the technology works and about the records kept by carriers. Unfortunately, video of the hearing doesn't appear to be available online anywhere, at least at the moment.
Update 5/16/12: An updated version of my testimony is available at https://www.mattblaze.org/papers/blaze-gps-20120517.pdf, as a statement for the record at a house hearing on the "GPS Act".

Back in 1995, Bruce Schneier asked me to write an "afterword" for the second edition of Applied Cryptography. Perhaps to his chagrin, I couldn't think of any better way to sum up a book about cryptography than to dismiss what was then a popular delusion about the subject: that it, above all else, held the secret for securing computers.

1995 now seems like a long time ago, technically and culturally. The Web was barely around. Highly connected people had fax lines at home. The Soviet Union had only recently dissolved. I could see the World Trade Center from my bedroom window.

Essays written that long ago, especially those about rapidly changing technology, can be a bit embarrassing to read -- conspicuously oblivious to some fast approaching meteorite that would shortly make the author's basic assumptions extinct. Or they might seem retrospectively obvious and trite: war is bad, puppies are cute, and computers are insecure.

And so it was with some trepidation that I recently dusted off my copy of Bruce's book and found myself staring at my thoughts on cryptography from the previous century.

A decade ago, I observed that commercial certificate authorities protect you from anyone from whom they are unwilling to take money. That turns out to be wrong; they don't even do that much.

SSL certificates are the primary mechanism for ensuring that secure web sites -- those displaying that reassuring "padlock" icon in the address bar -- really are who they purport to be. In order for your browser to display the padlock icon, a web site must first present a "certificate", digitally signed by a trusted "root" authority, that attests to its identity and encryption keys.

Unfortunately, through a confluence of sloppy design, naked commercial maneuvering, and bad user interfaces, today's web browsers have evolved to accept certificates issued by a surprisingly large number of root authorities, from tiny, obscure businesses to various national governments. And a certificate from any one of them is usually sufficient to bless any web connection as being "secure".

What this means is that an eavesdropper who can obtain fake certificates from any certificate authority can successfully impersonate every encrypted web site someone might visit. Most browsers will happily (and silently) accept new certificates from any valid authority, even for web sites for which certificates had already been obtained. An eavesdropper with fake certificates and access to a target's internet connection can thus quietly interpose itself as a "man-in-the-middle", observing and recording all encrypted web traffic traffic, with the user none the wiser.

But how much of a threat is this in practice? Are there really eavesdroppers out there -- be they criminals, spies, or law enforcement agencies -- using bogus certificates to intercept encrypted web traffic? Or is this merely idle speculation, of only theoretical concern?

A paper published today by Chris Soghoian and Sid Stamm [pdf] suggests that the threat may be far more practical than previously thought. They found turnkey surveillance products, marketed and sold to law enforcement and intelligence agencies in the US and foreign countries, designed to collect encrypted SSL traffic based on forged "look-alike" certificates obtained from cooperative certificate authorities. The products (apparently available only to government agencies) appear sophisticated, mature, and mass-produced, suggesting that "certified man-in-the-middle" web surveillance is at least commonplace and widespread enough to support an active vendor community. Wired's Ryan Singel reports in depth here.

It's worth pointing out that, from the perspective of a law enforcement or intelligence agency, this sort of surveillance is far from ideal. A central requirement for most government wiretapping (mandated, for example, in the CALEA standards for telephone interception) is that surveillance be undetectable. But issuing a bogus web certificate carries with it the risk of detection by the target, either in real-time or after the fact, especially if it's for a web site already visited. Although current browsers don't ordinarily detect unusual or suspiciously changed certificates, there's no fundamental reason they couldn't (and the Soghoian/Stamm paper proposes a Firefox plugin to do just that). In any case, there's no reliable way for the wiretapper to know in advance whether the target will be alerted by a browser that scrutinizes new certificates.

Also, it's not clear how web interception would be particularly useful for many of the most common law enforcement investigative scenarios. If a suspect is buying books or making hotel reservations online, it's usually a simple (and legally relatively uncomplicated) matter to just ask the vendor about the transaction, no wiretapping required. This suggests that these products may be aimed less at law enforcement than at national intelligence agencies, who might be reluctant (or unable) to obtain overt cooperation from web site operators (who may be located abroad).

Whether this kind of surveillance is currently widespread or not, Soghoian and Stamm's paper underscores the deeply flawed mess that the web certificate model has become. It's time to design something better.

It's been a frighteningly confusing week for frequent flyers (and confirmed cowards) like me. First we had the Underpants Bomber, his Christmas-day attempt to take down a Detroit-bound flight thwarted by slow-acting chemistry and quick-thinking passengers. Next -- within a day -- came inexplicable new regulations that seemed designed more to punish the rest of us than to discourage future acts of terrorism. The new rules were unsettling not just because they seemed as laughably ineffective as they were inconvenient, but because they suggested that the authorities had no idea what to do, no real process for analyzing and reacting to potential new threats. As the Economist was moved to write, "the people who run America's airport security apparatus appear to have gone insane".

A few days later the TSA, to its credit, rolled back some of the more arbitrarily punitive restrictions -- in-flight entertainment systems can now be turned back on, and passengers are, at the airline's discretion, again permitted to use the toilets during the last hour of flight.

But while a degree of sanity may have returned to some of the rules, the TSA's new security philosophy appears to yield significant advantage to attackers. The current approach may actually make us more vulnerable to disruption and terror now than we were before.

If you can climb a fifteen foot ladder and fit through a two foot diameter hole, you can, with a bit of advance planning, take an extensive "top-to-bottom" tour of a Titan II ICBM launch complex, complete with missile silo and missile. Best of all, you no longer have to trespass or join the Air Force to do it.

And so I just returned from Sahuarita, AZ and the Titan Missile Museum, a place known during most of the cold war as SMS Launch Site 571-7. I spent the better part of the day beneath the surface of the earth, part of a group of six hardy nuclear tourists under the direction of Lt. Col. Chuck Smith (USAF, retired, a former "missileer" at the site), exploring the nuts, bolts and welds of Armageddon.

At the peak of the cold war, there were over 1,000 nuclear missiles in buried silos located throughout sparsely populated areas of the continental United States, all fueled and ready to be launched toward the Soviet Union on a few minutes notice. From 1963 through 1984, this included 54 Titan II missiles at sites in Arizona, Arkansas and Kansas, each equipped with a W-53 warhead capable of delivering a nine megaton thermonuclear yield. Nine megatons is horrifically destructive even by the outsized standards of atomic bombs, capable of leveling a good size city in a single blast. And the Soviets had at least as many similar weapons aimed right back at us.

How did we keep from blowing ourselves up for all those years?

This week in Chicago, Micah Sherr, Gaurav Shah, Eric Cronin, Sandy Clark, and I have a paper at the ACM Computer and Communications Security Conference (CCS) that's getting a bit more attention than I expected. The paper, Can They Hear Me Now? A Security Analysis of Law Enforcement Wiretaps [pdf] examines the standard "lawful access" protocols used to deliver intercepted telephone (and some Internet) traffic to US law enforcement agencies. Picking up where our 2004 analysis of wireline loop extender wiretaps [pdf] left off, this paper looks at the security and reliability of the latest communications surveillance standards, which were mandated by the 1994 Communications Assistance for Law Enforcement Act (CALEA). The standards, it turns out, can leave wiretaps vulnerable to manipulation and denial of service by surveillance targets who employ relatively simple technical countermeasures.

Of particular concern to law enforcement and others who rely on wiretap evidence is the fact that the protocols can be prevented not just from collecting accurate call content (which can already be obscured by a target using encryption), but also from collecting the metadata record -- who called whom and when. Metadata-only taps (called "pen registers" for historical reasons) make up more than 90% of legal wiretaps in the US. Call metadata, which over time reveals a suspect's "community of interest" and behavior patterns, can be more revealing to an investigator than the content. Many agencies use software that automatically aggregates and analyzes call metadata to discover the members (and structure) of suspected criminal networks.

The wiretap standard, called ANSI J-STD-025, was originally designed to cover only the low-bandwidth voice telephone services that existed in the early 1990's. But as the communications services that law enforcement agencies might want to tap have expanded -- think SMS, 3G internet, VoIP, and so on -- the standard has been "patched" to allow the delivery of more and more different kinds of traffic. Unfortunately, many of these new services are a poor fit for the tapping architecture, especially in the way status messages are encoded for delivery to law enforcement and in the way backhaul bandwidth is provisioned. In particular, many modern services make it possible for a wiretap target to generate messages that saturate the relatively low bandwidth "call data channels" between the telephone company and the government, without affecting his or her own services. Worse, these channels are shared among all the taps in a particular central office, so a single person employing countermeasures can suppress wiretaps of other targets as well.

Just to be clear, we don't suggest that anyone actually do these things in the hopes of thwarting a government wiretap. Aside from being somewhat technically difficult, there would be no way to be sure that the countermeasures were actually working. And I know of no evidence that criminals are actually using these techniques today. (Of course, a determined and technically savvy criminal could prove me wrong about this.)

The real problem is that these protocols -- used in the most serious criminal investigations -- were apparently designed and deployed (and mandated in virtually every communications switch in the US) without first subjecting them to a meaningful security analysis. They were engineered to work well in the average case, but ignored the worst case of an adversary trying to create conditions unfavorable to the eavesdropper. And as the services for which these protocols are used have expanded, they've created a wider range of edge conditions, with more opportunities for manipulation and mischief.

That's a familiar theme for security engineers, and the CALEA wiretap standard is hardly the first example of a serious protocol being deployed without considering what an adversary might do. Unfortunately, it probably won't be the last, either.

I wrote the "Secure Systems" column in the September/October 2009 IEEE Security and Privacy, which is hitting the streets just about now. You can read the full column, "Taking Surveillance out of the Shadows", at www.mattblaze.org/papers/mab-sec-200909.pdf [pdf]. The subject, familiar to readers here, is wiretapping gone wrong.

Wiretapping has been controversial lately, often framed, rightly or wrongly, as a zero-sum battle between our right to privacy on the one hand and the needs of law enforcement and intelligence agencies on the other. But in practice, surveillance is about more than policy and civil liberties -- it's also about technology. Reliably intercepting traffic in modern networks can be harder than it sounds. And, time and again, the secret systems relied upon by governments to collect wiretap intelligence and evidence have turned out to have serious problems. Whatever our policy might be, interception systems can -- and do -- fail, even if we don't always hear about it in the public debate.

Indeed, the recent history of electronic surveillance is a veritable catalog of cautionary tales of technological errors, risks and unintended consequences. Sometime mishaps lead to well-publicized violations of the privacy of innocent people. There was, for example, the NSA's disclosure earlier this year that it had been accidently "over-collecting" the communications of innocent Americans. And there was the discovery, in 2005, that the standard interfaces intended to let law enforcement tap cellular telephone traffic had been hijacked by criminals who were using them to tap the mobile phones of hundreds of people in Athens, Greece.

Bugs in tapping technology don't always let in the bad guys; sometimes they keep out the good guys instead. Cryptographers may recall the protocol failures in the NSA's "Clipper" key escrow system [pdf], in which wiretaps could be defeated easily by exploiting a weak authentication scheme during the key setup. More recently, there was the discovery in 2004, by Micah Sherr, Sandy Clark, Eric Cronin and me, that law enforcement intercepts of analog phones can be disabled just by sending a tone down the tapped line [pdf].

What's going on here? It's hard to think of another law enforcement technology beset by as many, or as frequent, flaws as are modern wiretapping systems. No one would tolerate a police force regularly hobbled by exploding guns, self-opening handcuffs, stalled radio cars, or contaminated evidence bags. Yet many of the systems we depend on to track suspected criminals and spies have failed just as spectacularly, if more quietly.

A common factor in these failed systems is that they were designed and deployed largely in secret, away from the kind of engineering scrutiny that, as security engineers know well, is essential for making systems robust. It's a natural enough reflex for law enforcement and intelligence agencies to want to keep their surveillance technology under wraps. But while it may make sense to keep secret who is under surveillance, there's no need to keep secret how. And the track record of current systems suggests a process that is seriously, even dangerously, broken.

Fortunately, unlike some aspects of the debate about wiretapping, reliability isn't a political issue. The flaws in these systems cut across ideology. No one is served by defective technology that spies on the wrong people or that lets criminals, spies, or terrorists evade legal wiretaps. If surveillance is to protect us, it has to come out of the shadows.

Photo: Law enforcement "loop extender" tap for analog phone lines.

Stewart Baker, former director of policy at the Department of Homeland Security, the parent agency of the TSA, took me to task for my recent posting about the new TSA boarding pass scanners being installed at airport security checkpoints.

My observation was that the ID checkpoint is insufficient and in the wrong place; fixing the Schneier/Soghoian attack requires that a strong ID check be performed at the boarding gate, which the new system still doesn't do. Stewart says that the TSA security process doesn't care what flight someone is on as long as they are screened properly and compared against the "no fly" list.

Maybe it doesn't; the precise security goals to be achieved by identifying travelers have never been clearly articulated, which is an underlying cause of this and other problems with our aviation security system. But the TSA has repeatedly asserted that passenger flight routing is very much a component of their name screening process. For example, the regulations governing the Secure Flight program published last October in the Federal Register [pdf] say that "... TSA may learn that flights on a particular route may be subject to increased security risk" and so might do different screening for passengers on those routes. I don't know whether that's true or not, but those are the TSA's words, not mine.

Anyway, Stewart's confusion about the security properties of the protocol, and about my reasons for discussing them notwithstanding, the larger point is that aviation security is a complex (and interesting) problem in the discipline that I've come to understand as "human-scale security protocols".

I first wrote about human scale security as a computer science problem back in 2004 in my paper Toward a broder view of security protocols [pdf]. Such protocols share much in common with the cryptographic authentication and identification schemes used in computing: they're hard to design well and they can fail in subtle and surprising ways. Perhaps cryptographers and security protocol designers have something to contribute toward analyzing and designing better systems here. We can certainly learn something from studying them.

In 2003, Bruce Schneier published a simple and effective attack against the TSA's protocol for verifying a flyer's identity on domestic flights in the US. Nothing was done until 2006, when Chris Soghoian, then a grad student at Indiana University, created an online fake boarding pass generator that made it a bit easier to carry out the attack. That got the TSA's attention: Soghoian's home was raided by the FBI and he was ordered to shut down or face the music. But the TSA still didn't change its flawed protocol, and so for more than five years, despite the inconvenience of long security lines and rigorous checks of our government-issue photo IDs at the airport, it has remained possible for bad guys to exploit the loophole and fly under a fake name. I blogged about the protocol failure, and the TSA's predictably defensive, shoot-the-messenger reaction to it, in this space a couple of years ago.

Well, imagine my surprise yesterday when I noticed something new at Philadelphia International Airport: the TSA ID checker was equipped not just with the usual magnifying glass and UV light, but with a brand new boarding pass reader. The device, which did not yet seem to be in use, apparently reads and validates the information encoded on a boarding pass and displays the passenger name as recorded in the airline's reservation record. According to the TSA blog, boarding pass readers are being rolled out at selected security checkpoints, partly to to enable "paperless" boarding passes on mobile phones, but also to close the fake boarding pass loophole.

Unfortunately, the new system doesn't actually fix the problem. The new protocol is still broken. Even when the security checkpoint boarding pass readers are fully operational, it will still be straightforward to get on a flight under a false name.