Banking Security

Banks have traditionally led the way in fighting fraud from both insiders and outsiders. They have developed protection methods against insider fraud including double-entry book-keeping, functional separation, and compulsory holiday periods for staff, and they recognise the need for regular security audits. These methods successfully reduce fraud to an acceptable level for banks, and in conjunction with an appropriate legal framework for liability, they can also protect customers against the consequences of fraud.

However, the increasing complexity of bank computer systems has not been accom­panied by sufficient development in understanding of fraud prevention methods. The introduction of HSMs to protect customer PINs was a step in the right direction, but even in 2002 these devices have not been universally adopted, and those that are used have been shown time and time again not to be impervious to attack [1, 2, 5]. Typical banking practice seeks only to reduce fraud to an acceptable level, but this translates poorly into security requirements; it is impossible to accurately assess the security expo­sure of a given flaw, which could be an isolated incident or the tip of a huge iceberg. This sort of risk management conflicts directly with modern security design practice where ro­bustness is crucial. There are useful analogues in the design of cryptographic algorithms. Designers who make "just-strong-enough" algorithms and trade robustness for speed or export approval play a dangerous game. The cracking of the GSM mobile phone cipher A5 is but one example [3].

And as "just-strong-enough" cryptographic algorithms continue to be used, the risk of fraud from brute force PIN guessing is still considered acceptable, as it should take at least 10 minutes to guess a single PIN at the maximum transaction rate of typical modules deployed in the 80s. Customers are expected to notice the phantom withdrawals and report them before the attacker could capture enough PINs to generate a significant liability for the banks. Even with the latest HSMs that support a transaction rate ten times higher, the sums of money an attacker could steal are small from the perspective of a bank.

But now that the PIN decimalisation table has been identified as an security relevant data item, and the attacks described in this paper show how to exploit uncontrolled access to it, brute force guessing is over two orders of magnitude faster. Enough PINs to unlock access to over Ј2 million can be stolen in one lunch break!

A more sinister threat is the perpetration of a smaller theft, where the necessary transactions are well camouflaged within the banks audit trails. PIN verifications are not necessarily centrally audited at all, and if we assume that they are, the 15 or so transactions required will be hard for an auditor to spot amongst a stream of millions. Intrusion detection systems do not fare much better - suppose a bank has an extremely strict audit system that tracks the number of failed guesses for each account, raising an alarm if there are three failures in a row. The attacker can discover a PIN without raising the alarm by inserting the attack transactions just before genuine transactions from the customer which will reset the count. No matter what the policies of the intrusion detection system it is impossible to keep them secret, thus a competent programmer could evade them. The very reason that HSMs were introduced into banks was that mainframe operating systems only satisfactorily protected data integrity, and could not be trusted to keep data confidential from programmers.

So as the economics of security flaws like these develops into a mature field, it seems that banks need to update their risk management strategies to take account of the volatile nature of the security industry. They also have a responsibility to their customers to reassess liability for fraud in individual cases, as developments in computer security con­tinually reshape the landscape over which legal disputes between bank and customer are fought.