The Initial Costs and Maintenance Costs of Protocols
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
- PDF / 123,504 Bytes
- 3 Pages / 430 x 660 pts Page_size
- 67 Downloads / 189 Views
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 N is to start with version N -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. But attitudes are changing. The hassles caused by vulnerable machines (both directly and indirectly) continue to grow, and consumer expectations harden. Meanwhile, all sorts of consumer durables are acquiring CPUs and communications. If an airconditioner turns out to have a stack overflow in its TCP/IP code, how do you patch it? If you don’t, then how do you deal with a virus that switches millions of airconditoners on and off simultaneously, causing a cascade failure of the power grid? And even before we get to the nirvana of pervasive computing, the economics of patching ordinary PCs has become a large and growing topic in security economics. A number of ideas have emerged recently about designing protocols for maintainability. In [1], for example, we explored what happens when a principal deploys ‘smart dust’ in an area that is shortly afterwards attacked by an opponent. Assuming that ultra-low-cost dust motes cannot be made tamper-resistant, the opponent can recover shared secrets by reverse engineering a handful of motes and can then eavesdrop on any links whose communications she happens to have monitored. This turns out to be equivalent, in some sense, to a network whose B. Christianson et al. (Eds.): Security Protocols 2005, LNCS 4631, pp. 333–335, 2007. c Springer-Verlag Berlin Heidelberg 2007
334
R. Anderson
nodes must send initial key material to each other in the clear. Does this make security impossible? Not at all. Under assumptions that are reasonable in many app
Data Loading...
