Designers of cryptographic systems are at a disadvantage to most other engineers, in that information on how their systems fail is hard to get: their major users have traditionally been government agencies, which are very secretive about their mistakes. In this article, we present the results of a survey of the failure modes of retail banking systems, which constitute the next largest application of cryptology. It turns out that the threat model commonly used by cryptosystem designers was wrong: most frauds were not caused by cryptanalysis or other technical attacks, but by implementation errors and management failures. This suggests that a paradigm shift is overdue in computer security; we look at some of the alternatives, and see some signs that this shift may begetting under way.

This talk follows on more from the talks by Larry Paulson and Giampaolo Bella that we had earlier. The problem I’m going to discuss is, what’s the next problem to tackle once we’ve done crypto protocols? We keep on saying that crypto-protocols appear to be “done ” and then some new application comes along to give us more targets to work on – multi-media, escrow, you name it. But sooner or later, it seems reasonable to assume, crypto will be done. What’s the next thing to do? The argument I’m going to make is that we now have to start looking at the interface between crypto and tamper-resistance. Why do people use tamper resistance? I’m more or less (although not quite) excluding the implementation of tamper resistance that simply has a server sitting in a vault. Although that’s functionally equivalent to many more portable kinds of tamper resistance, and although it’s the traditional kind of tamper resistance in banking, it’s got some extra syntax which becomes most clear when we consider the Regulation of Investigatory Powers (RIP) Bill. When people armed with decryption notices are going to be able to descend on your staff, grab keys, and forbid your staff from telling you, then having these staff working in a Tempest vault doesn’t give the necessary protection.

Designers of cryptographic systems are at a disadvantage to most other engineers, in that information on how their systems fail is hard to get: their major users have traditionally been government agencies, which are very secretive about their mistakes. In this article, we present the results of a survey of the failure modes of retail banking systems, which constitute the next largest application of cryptology. It turns out that the threat model commonly used by cryptosystem designers was wrong: most frauds were not caused by cryptanalysis or other technical attacks, but by implementation errors and management failures. This suggests that a paradigm shift is overdue in computer security � we lookatsomeofthealternatives, and see some signs that this shift may begetting under way. 1