[an error occurred while processing this directive] An error occured whilst processing this directive
4pm Tuesday 26th September 2006
Room 2511, JCMB, King's Buildings
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?