Catálogo de publicaciones - libros

This is a short talk on topology of covert conflict, comprising joint work I’ve been doing with Ross Anderson. The background of this work is the following. We consider a conflict, and there are parties to the conflict. There is communication going on that can be abstracted as a network of nodes (parties) and links (social ties between the nodes). We contend that once you’ve got a conflict and you’ve got enough parties to it, these guys start communicating as a result of the conflict. They form connections, that influences the conflict, and the dynamics of the conflict in turn feeds the connectivity of the unfolding network.

Modern conflicts often turn on connectivity: consider, for instance, anything from the American army’s attack on the Taleban in Afghanistan, and elsewhere, or medics who are trying to battle a disease, like Aids, or anything else. All of these turn on, making strategic decisions about which nodes to go after in the network. For instance, you could consider that a good first place to give condoms out and start any Aids programme, would be with prostitutes.

Software-engineering academics focussed for many years on the costs of developing the first version of a product, and ignored the costs of subsequent maintenance. We taught our students the ‘waterfall model’, and biased research towards the sort of tools and ideas that complemented it, such as formal methods. Meanwhile the economics of software had changed. Software is now so complex that the only way to build version is to start with version -1. Iterative development methodologies now rule, and the tools that real developers say have helped them most in the last fifteen years are not theorem provers, but automated regression-testing and bug-reporting systems. Nowadays, the maintenance is the product.

Security engineers have been falling into a similar trap. For years, we thought that the problem of authentication began and ended with trustworthy bootstrapping. Once Alice and Bob shared that elusive session key - and could prove mathematically that no-one else did - we could type up the research paper and head for the pub. Again, the real world has changed. Security maintainability is the elephant in the living room; people know there’s an awful problem but are generally too polite to mention it (especially as we don’t really know what to do with the beast). Vendors used to not care very much; after all, people replace their mobile phones every year, and their PCs every three to five years, so why not just wait for the vulnerable equipment to be thrown on the skip? With luck, vulnerability scares might even help stoke the upgrade cycle.

I’d planned to talk about usability and maintainability – in my view, likely to be the two most important research topics in security over the next five years. As everybody’s talked about usability, I will talk a bit more about maintainability.

In the old days we always considered that security was about bootstrapping. Once Alice and Bob could be induced to share a key, job done: we go off down the pub and the following day we write the paper. This is a bit like software engineering 30 years ago where people just studied the waterfall model. But the real world nowadays is different. Nobody’s interested in waterfall; everybody’s interested in evolutionary development, extreme programming and so on. The maintenance is the product - because almost all your costs fall at points in the system development lifecycle other the first one.

Good evening Ladies and Gentlemen.

There comes a time when people at a technical conference like this need something more relaxing. A change of pace. A shift of style. To put aside all that work stuff and think of something refreshingly different.

So let’s talk about coding theory. There are perhaps some of you here tonight who are not experts in coding theory, but rather have been dragged here kicking and screaming. So I thought it would be a good idea if I gave you a sort of instant, five minute graduate course in coding theory.