Personal tools
You are here: Home Events Abstract Archives 2006-2007 Satan's Computer, Revisited

Satan's Computer, Revisited

Ross Anderson Cambridge University 4pm Tuesday 26th September 2006 Room 2511, JCMB, King's Buildings

Designers of distributed system have spent twenty-five years struggling with security protocols. These protocols, which are used to authenticate users and authorise transactions, may involve the exchange of 3-5 messages, and one would think that programs of this complexity would be easy to get right. But bugs keep on being discovered in protocols, even years after they were first published. Almost ten years ago, Roger Needham and I described protocol design as Programming Satan's Computer: the problem is the presence of a hostile opponent, who can alter messages at will. In effect we're trying to program a computer which gives answers that are subtly and maliciously wrong at the most inconvenient possible moment.

Six years ago, I started applying protocol ideas to study the security of application programming interfaces (APIs). In applications from banking through utility metering to defence, some critical operations are delegated to tamper-resistant cryptographic processors. These devices are driven by a stream of transactions from a host computer, and the set of possible transactions constitutes their API. I found combinations of transactions that broke security; Mike Bond found many more, and further API attacks have been discovered by Jolyon Clulow and Eli Biham. Mike, Jolyon and I have discovered that most security processors on the market can be defeated by sending them conbinations of transactions which their designers had not anticipated. The early attacks are described in our paper API Level Attacks on Embedded Systems.

Where now? I will argue that API security problems are not just important to designers of cryptoprocessors. First, Microsoft's new Vista operating system will invite application programmers to decompose their code into a trusted part (the NCA) and a larger untrusted part; this will bring API trust issues into the mainstream. Second, API security connects protocol analysis with the composition problem - the problem that connecting two systems that are secure in isolation can give a composite system that leaks. This had previously been seen as a separate issue, tackled with different tools. Finally, there is a link emerging between protocol analysis and secure multiparty computation. How can a computation be shared between a number of parties, if some concerted minority of them may collude to disrupt the computation in a way that leaks private data?

Document Actions