From: rja14@cl.cam.ac.uk (Ross Anderson)
Subject: Re: ATM fraud
Reply-To: rja14@cl.cam.ac.uk (Ross Anderson)
Organization: U of Cambridge, England
Date: Mon, 9 Nov 1992 11:35:35 GMT

I'm doing research on fraud for a UK law firm, J Keith Park & Co, who are 
currently running a class action against the UK banks on behalf of hundreds 
of customers who've been ripped off by ATMs.

People often find debits on their accounts which they didn't make. It seems
that the banks' transaction error rate is somewhere between 1 in 10,000 and 1 
in 100,000 (depending on the bank) and if you're unlucky you get charged
someone else's withdrawal (or one of your own twice).

There are also lucky people who make withdrawals for years and don't get 
debited. Perhaps electronic banking should fall under casino legislation!

In the old days of brass bound ledgers you could go to the manager and say 
`produce the voucher'. He had to do this or give you your money back.

But now that banking is electronic, they just say that the computer can do no
wrong and tell you to get stuffed.

The Bank of England supports the banks' argument that there is an overriding
public interest in `maintaining confidence in the banking system' (the same 
argument they used to cover up the problems of the Bank of Crooks and Cocaine 
International).

Needless to say, there's a growing amount of ATM fraud; bank staff know that if
they rip off customers, the customers' complaints will not be taken seriously. 
It's a good job that most bank tellers are honest!

Back in March I wrote an article on the various ways in which the ATM system 
gets ripped off. This is now extremely out of date as I have come across a lot 
of new tricks since. However here it is for anyone who's interested.

Ross Anderson
University of Cambridge Computer Laboratory
Pembroke Street, Cambridge CB2 3QG, England
rja14@cl.cam.ac.uk

*****************************************************************************

\documentstyle[a4,11pt]{article}
\parskip 12pt plus 1pt minus 1pt

\begin{document}

\begin{center}
{\LARGE \bf Security Issues of PIN Based Payment Systems}

\vspace{3.5ex}

{\em Ross J. Anderson\\
Computer Laboratory\\
Pembroke Street, Cambridge CB2 3QG}

\end{center}

\vspace{3.5ex}

{\noindent\Large\bf Abstract}

We give an outline history of the development of Automatic Teller Machines 
(ATMs). Most of these systems still use a combination of magnetic strip card 
and personal identification number (PIN) to identify users. We examine a 
number of threats to the current ways of managing PINs, and outline some 
options for designers wishing to create more secure systems in the future.

\vspace{3.5ex}
{\noindent\bf Keywords:} {\em computer security, cryptography, banking, ATMs, 
PINs, fraud, biometrics, smartcards}

\section{Introduction}

The ancestry of modern payment systems can be traced to twelfth century
Italy, where city states such as Genoa and Venice established trading empires
which stretched the length and breadth of the Mediterranean and eventually as
far as China. One of the main problems encountered by their merchants was 
that of piracy.

The Roman empire had been built on military prowess and had effectively
suppressed piracy in the Mediterranean during the rule of Julius Caesar. In 
the modern epoch, however, the Barbary pirates continued to plague the trade
of Southern Europe until after the Napoleonic war.

This combination of renascent prosperity and military weakness was very
hard for merchants, who had to carry gold and silver with them to trade. 
It created a demand for a safe means of effecting payments, and this was met
by the moneychangers, who began to issue gold receipts which could be traded.
Money became a paper document, validated by a banker's signature, which
entitled the bearer, or a named beneficiary, to receive value. This went some
way to solving the robbery problem, but at the cost of creating a new risk: 
forgery.

\pagebreak

During the ensuing eight hundred years, many countries have developed a body 
of statute and case law which seeks to allocate liability in the event
of a forged document being discovered in the payments system. However, this
law does not tackle the basic problem of how to spot a forged document reliably
in the first place. So long as the checking process involves visual inspection 
of a handwritten signature, it will remain slow and error prone, and may be
completely omitted where large transaction volumes make it expensive, or in 
clearing networks where the specimen signature is in a different location from 
the voucher entry process.

The first attempts at solving this problem were made during the mid nineteenth
century. As the telegraph pioneers linked up the world's main cities, 
businessmen could close deals within minutes, and demanded the ability to
settle them at the same speed. The early telegraph systems could not, however, 
carry the graphic information needed to represent a traditional signature, and
a new approach was needed.

This was the `test key' - a sequence of digits which was obtained by applying
the significant digits of the transaction to a permutation table and hashing 
the results. This test key, once calculated, was appended to the telegraphic
message and functioned as a digital signature.

Test keys are still in use today, particularly in less developed countries 
where banks do not possess the equipment needed to participate in modern 
wholesale funds transfer networks. However their main influence has been in the
adoption of the personal identification number, or PIN, as the near universal 
means of identifying users of ATM networks.

\section{The Development of ATM Systems}

Automatic Teller Machines, or ATMs, were like most computer systems in that
they were originally developed without much concern for security other than
the obvious protection against violent external assault. The first examples
simply accepted a punched card and a PIN, checked the PIN against the card,
and issued a fixed amount (\pounds 10 in the UK in the early 1970's). The
card was retained by the ATM and returned to the customer at the end of the 
month. The PIN, which was inspired by the test key, was introduced for a 
simple reason: without it, the card could have been used by anyone to draw 
cash, and so would have been of no more use than cash to most customers.
The security procedures for these early machines were quite primitive, being
essentially limited to balancing cash loaded against cards captured, and the 
PIN was really an add-on, an incentive to get customers to use ATMs 
and thus save teller time and costs.

\pagebreak

A fraud problem arose in some countries overseas, where criminals (and in 
Israel, even enterprising but misguided students) worked out the relationship
between the holes punched in the card and the corresponding PIN. There was 
also a concern about what would happen if a customer repudiated a transaction. 
How could a bank satisfy a judge the their system was secure, even in the face 
of testimony from a plausible witness?

These pressures led to a number of research programs being carried out into 
ATM security, and in particular PIN security, in the late 1970's and early 
1980's, with the aim of tackling the forgery problem once and for all. At
this time, computer security was an embryonic discipline, and inspiration was 
drawn from US government guidelines. These defined three categories of
identification data as being (roughly) something the user knows, like a 
password; something he has, like a key; and something he `is', such as his
voice, his signature or his facial features. Users accessing classified 
systems had to pass checks from two of these three categories.

At that time, automated recognition of faces, fingerprints and voiceprints was 
too unreliable, and this forced designers of unattended systems such as ATMs
to base user identification on the first two criteria, in effect on a password 
and a token. Moreover, studies of time sharing computer systems had shown 
that, given the chance, many people will choose a password that is easy for
others to guess, such as their initials. For this reason, the research program 
led designers to specify a randomly generated password, and considerations of 
cost, reliability and user acceptance dictated that these passwords should be 
numeric only. In this way, the status of the PIN was confirmed.

A number of systems were developed, of which two captured most of the market. 
These were the IBM system, launched in 1979, which had been developed by Meyer,
Matyas and others at IBM; and the VISA system, which had been developed by 
Carl Campbell, launched by his company Transaction Security Products Inc. 
in 1981 and taken over by VISA in 1983. They share a core concept, which is 
described in the next section.

\section{Derived PINs}

The IBM and VISA systems relate the PIN to the account number in a secret 
way. The idea is to avoid having a file of PINs, as this file might be stolen 
or copied. and to give the option of remote validation of PINs in systems where
offline transactions are permitted. The definitive reference is [MM]; there is 
a shorter account in [DP].

We take the last five significant digits of the account number, and prefix 
them by eleven digits of validation data. These may be simply the first eleven
digits of the account number, or could be a function of the month of card 
issue. In any case, the resulting sixteen digit value is input to an
encryption algorithm (which for IBM and VISA systems is DES, the US Data
Encryption Standard algorithm), and encrypted using a sixteen digit key called
the PIN key. The first four digits of the result are decimalised, and the 
result is called the `Natural PIN'.

Many institutions started off by issuing the natural PIN to their customers. 
However, some institutions decided that they wished to offer their customers 
the facility to choose their own PIN, or to change a PIN if it became known to
somebody else, and for this reason there is a four digit number called the
offset, which is added to the natural PIN to give the customer PIN, that is,
the number which must be entered at the ATM keyboard to authorise a 
transaction.

Here is an example of the process:

{\tt 
\begin{tabbing}
First four digits decimalised (Natural PIN) are : \= 01234567890\=12345 \kill
Account number: \> 4506602100091715 \\
Last 5 digits: \> \> 91715\\
Validation data: \> 88070123456 \\
Input to DES algorithm: \> 8807012345691715 \\
PIN key: \> FEFEFEFEFEFEFEFE \\
Result of DES algorithm: \> A2CE126C69AEC82D \\
Decimalisation table: \> 0123456789012345 \\
First four digits decimalised (Natural PIN): \> 0224\\
Offset: \> 6565\\
Customer PIN: \> 6789\\
\end{tabbing}
}

It should be clear that the security of the system depends on keeping the
PIN key absolutely secret. However there are other aspects of system design
which are also important in deterring certain types of attack, and we
shall see examples of this below.

\section{The IBM and VISA Systems}

In the original IBM system design, the PIN was always validated at the ATM.
This meant that the PIN key had to be present in two places, namely at the
central computer site where PIN mailers were printed for new customers, and 
within each ATM itself. In order to limit the number of staff with access to 
the PIN key, a facility was provided whereby this key could be supplied in 
two printed components. These would be carried to the ATM by two separate 
officials and input at the keyboard there, whereupon they would combine to 
form the live PIN key.

\pagebreak

It was still possible however for bank staff to get at the live PINs, or
keys, or both, as the IBM products (the 3848, PCF and CUSP) only provided 
the encryption step of the above process, and left the other manipulations to 
be performed by a mainframe computer program, which had to be written 
anew by each bank. For this reason, the overall system security was predicated 
not just on the cryptographic product, but also on the control exercised over 
general system resources and, crucially, on the skill and integrity of each 
bank's system development and maintenance staff.

Carl Campbell's innovation was to devise a system in which no key or PIN ever 
becomes available to any bank employee. This system is quite involved and 
details of one implementation can be found in, for example, [NSM]. In what 
follows, we give a brief summary.

The basic concept is that all the central cryptographic operations are
performed in a device called a security module (SM) which controls all
of an institution's keys and PINs. The SM produces master keys for ATMs,
which, as in the IBM case, are printed in separate components for secure
conveyance to the ATM, and similar keys (called `Zone keys') for conveyance
to other institutions or other SMs in the same institutions.

Once a remote device, be it an ATM or another SM, has been equipped with
a master key (or zone key), it is supplied with working keys. These are keys
which will be used to encrypt PINs, other keys, or service messages during
routine operation of the system. The management of these working keys is fully
automatic.

The hierarchy of master keys, zone keys and working keys is so devised that
it should not be possible for any individual in the bank to get hold of the 
clear value of any PIN or key. Once they have been generated, all keys and PINs
appear only as encrypted data blocks while outside of secure devices such as 
ATMs and SMs. As for the initial generation and printing process, this is 
performed on special printers attached to the SM, so that it can be closely 
controlled. PINs are printed on security mailers and dispatched directly to 
the branch or post office; keys are produced in multiple components which are 
handed at once to separate officials.

The security module concept has now finally been adopted by IBM in their 
latest product line, the 4753. However, this only came after two international
banking organisations, Mastercard and VISA, issued regulations making the use
of security modules mandatory in interbank networks. These organisations are 
network providers and managers, and, when large numbers of banks connect their 
ATMs together, the security of the whole network can be that of its weakest 
link. For this reason, they considered the original IBM approach to be 
unacceptable, as it would make every bank's PIN security depend on the 
integrity of all the hundreds of thousands of technical staff who have access
to ATM and card issue systems in the twelve thousand member banks worldwide. 
Incidentally, IBM resisted this decision as it was seen as a criticism of IBM's
cryptographic strategy and product offerings.

A sample interbank transaction is described in the appendix, so that the
interested reader can acquire some feel for the mechanics of the security
module system.

There is no doubt that PINs give a useful first line of defence against fraud. 
Indeed, VISA reports that the incidence of fraud on systems which are PIN-based
is about one hundredth of that from signature-based cards. Given that fraud on
the latter varies from 0.1\% and 1\% depending on the country and the issuing 
bank, PINs must be saving billions. However, PIN-based systems have a number 
of weaknesses which are not always well understood, and as bankers become 
more complacent about their systems, and technical knowledge of them continues 
to spread, both the incidence of fraud and the likelihood of a really major 
loss continue to grow.

\section{Attacks on ATM Systems}

If an attacker gets hold of a bank's PIN key, the situation is potentially
disastrous. For that reason, attacks of this type will be considered 
separately in the next section. In this section, we describe a number of less 
dramatic ways in which an ATM system can be subverted.

(1) The system can be compromised easily by poor administration. For example, 
in February this year the author asked for an increased card limit: the bank 
sent not one, but two, cards and PINs through the post. This was a near miss: 
the cards arrived only a few days after intruders had got hold of the apartment
block's mail and torn it up looking for valuables. There appear to be no 
statistics available for losses arising from this kind of incident, but we 
expect that they account for thousands of cases a year.

(2) In our experience, banks in the English speaking world dismiss, or ask for
the resignation of, about one percent of their staff every year for 
disciplinary reasons. A nontrivial proportion of these are for petty fraud or
embezzlement, in which ATMs are often involved. A clearing bank with 50,000
staff, which issued PINs predominantly through the branches rather than by 
post, could expect about two incidents per business day of staff stealing cards
and PINs. These could be test cards, or cards otherwise used to milk the bank's
internal accounts; but it is simpler, and so much more common, for dishonest 
staff to issue duplicate cards on ordinary accounts, or help themselves to 
cards which have not yet been issued to customers. 

(3) It may in some cases be possible for a dishonest teller to pass to a 
customer's account a debit which masquerades as an ATM withdrawal, without 
going near the ATM system. Such facilities may be provided in general banking
systems in order to allow branch staff to rectify mistakes, and may be abused 
from time to time. An established policy of denying all liability for
`phantom withdrawals', and telling customers that they must have been defrauded
by their own relatives, may be expected to encourage this kind of embezzlement.

(4) Another source of trouble at some institutions has been the existence of 
undocumented test transactions. There was a test facility on one of the 
Olivetti 2000 series ATMs which would output ten banknotes when a fourteen 
digit sequence was entered at the keyboard. One bank published this sequence
in its branch manual, and there was a spate of fraud until all the banks using
this type of machine had changed the software to disable this transaction.

(5) Various program bugs and operational errors will also cause a certain
percentage of mistakes such as duplicate transactions and debits posted to the 
wrong account. These are familiar enough to heavy users of any bank's cheque
processing facilities, who correct them by reconciling their accounts and
demanding to see vouchers for stray debits. However, with ATM systems, the
customer cannot usually demand to inspect tally rolls, transaction logs and
balancing records; and any attempt at checking a disputed transaction is 
generally frustrated in various ways by the bank. In view of the precedent
set by dispute resolution on cheque accounts, this may be a weak point in 
the banks' legal case. From our own banking systems experience, we would 
expect an error rate of between 0.1\% and 0.01\% of transactions; this is in 
order-of-magnitude agreement with surveys which show that some 35\% of UK 
cardholders have experienced a `phantom withdrawal' at some time in their 
lives.

(6) In addition to the above general problems, there are a number of 
technical ways in which ATM systems can be attacked. One of the most 
famous, at least within the computer security community, occurred at the 
Chemical Bank in New York in about 1985. An ATM technician, who had been 
dismissed, stood in ATM queues and observed customers' PINs as they were 
entered. He would then pick up the discarded receipt, which contained the 
account number, and write this number to the magnetic strip of a blank 
card. He managed to steal over \$80,000 before the bank saturated the 
area with security men and caught him in the act. Needless to say, the 
emergence of worldwide ATM networks during the past few years makes such 
attacks much more easy to mount, and much more difficult to stop. In fact, 
the attack worked against Chemical Bank because they issued their customers 
with the natural PIN, so almost all their offsets were zero; and since then 
it has been standard security practice worldwide to print only the last six 
digits of the account number on the receipt, to issue cards with random 
offsets, or both.

\pagebreak

(7) An even more sophisticated attack was reported from the USA in 1988. In
this case, the fraudsters had constructed a vending machine which would 
accept any card and PIN, and dispense a packet of cigarettes. They placed this 
in a shopping mall, and used the PINs and magnetic strip information it
recorded to forge cards for use in ATMs. Attacks of this type cannot be 
prevented by purely technical means so long as the ISO standard 
magnetic card is used, and this incident has been a spur to the development of 
card types which are hard to forge, such as watermark cards and smartcards.

(8) Another technical attack relies on the fact that most ATM networks do not
encrypt the authorisation response to the ATM. This means that an attacker can
record a `pay' response from the bank to the machine, and continually replay it
until the machine is empty. This technique, known as `jackpotting', is not 
limited to outside `hackers' - it appears to have been used in South Africa in
1987 by a bank's operations staff, who used network control devices to jackpot 
ATMs where accomplices were waiting.

(9) Some banks decided to hold the encrypted PINs on a database. This meant
that a programmer, who knew that his own PIN was 1537, would observe that his
encrypted PIN was (say) {\tt 132AD6409BCA4331}, and then search the database 
for all other account numbers with the same PIN. If the bank has five 
million cards outstanding, there should be about five hundred of these - 
and using forged cards to take \pounds 50 from each of these accounts would 
yield a tidy \pounds 25,000. Furthermore, as these account holders would be
randomly distributed around the country, and since the one or two complaints 
per branch would be unnoticed among those arising from random errors, the 
chances of the fraud being detected would be quite small. For this reason, 
VISA recommends that where a file of encrypted PINs is to be held, the account 
number should be combined with the PIN before encryption, so as to make each 
encrypted block unique.

(10) Banks which used IBM encryption products such as the 3848 are open to much
more direct attacks. A system programmer can simply observe clear PINs going 
through the mainframe, compile a list of corresponding account numbers and
PINs, and make up forged cards.

Of the above, (1) to (3) will typically manifest as bogus transaction around 
the time of card issue, or after a loss has been reported. (5) to (10) will
present as phantom withdrawals on accounts in normal use; and of these,
(6) and (7) will tend to be geographically localised, while (5), (8), (9) and
(10) would usually result in frauds scattered at random throughout the issued
card base. However, if a bank has a policy of denying all disputed transactions
outright and keeps no central record of them, a fraud might be very far
advanced before it came to the attention of top management.

\pagebreak

\section{Security of the PIN Key}

There are a number of ways in which a PIN key can be obtained by an
attacker. In fact, there are two such incidents of which the author has 
personal knowledge, having consulted to the victim institutions.

(11) In the first, the bank had a policy that only IBM terminals could be 
purchased. The security modules they used, which were a standard product
supplied by VISA, would not accept IBM terminals but required VT type devices
instead. This caused a problem as the institution wished to establish a zone
key with a new network, and had no terminals with which to perform the required
transactions at the security module. The card development team were asked to 
help, and the project leader obligingly supplied a portable PC with 
communications software which emulated a VT100 terminal. With this the
internal auditors, senior managers and assorted dignitaries duly created 
the required zone keys and carted them off to the network switch. However, the
communications software had a facility to record all the transactions, and this
facility had been turned on by the miscreant. He later used the zone key to
decrypt the bank's PIN key.

(12) In the second, the bank had no proper ATM test environment. When it
decided to join a network, the equipment vendor's systems engineer could not 
get the system working and used undocumented tricks to get hold of the clear 
PIN key in order to debug the system.

In both these cases, the problem stemmed from poor management and was 
compounded by audit and security staff who were not really technically
aware. Most institutions would admit that the latter, at least, is a common 
enough problem - it is unlikely that good engineers will be happy for
long in a security role, unless they can become involved in research, product 
design or consultancy work. The banks affected were lucky, in that the damage 
was limited to embarrassment; but it is only a matter of time before a bank 
becomes very unlucky indeed, as there are a number of other ways in which 
a PIN key can be compromised.

(13) The most obvious vulnerability in many banking systems is that PIN keys 
are loaded into ATMs in order to facilitiate offline transactions. The usual 
procedure is that the PIN key is encrypted under the terminal master key and
downline loaded to the ATM as KMT(KP) during the first service transaction
after each maintenance operation. It follows that if the maintenance engineer
can get his hands on KMT, and then record KMT(KP), he can decrypt KP and hold 
the bank to ransom. In our experience, the control procedures surrounding 
the custody of the KMT component mailers at bank branches are weak and
this kind of attack is a very present possibility.

\pagebreak

(14) Where the encryption at the bank's mainframe computer is performed in 
software, such as using IBM's PCF product, the key can be found trivially by
programmers. Even where the bank changes to security modules, a knowledge of
the PIN key may persist for years afterward: it is, after all, useful in
debugging systems.

(15) Certain technical attacks are possible on certain makes of security
module by people with physical access to them. The author has twice needed to 
assist at such an attack: once for a bank which had lost a key for one of its
security module systems, and once to arrange to transfer a set of master keys
from one make of security module to another. In such cases, the bank is
competely at the mercy of the experts carrying out the operation.

(16) We have heard of cases where a bank has given live keys to an 
equipment vendor or maintenance organisation and asked them to set up or 
run part of the system. There have also been cases where PIN keys have been
shared between two or more institutions. In any case where the bank shares
a key, it can no longer be sure how secure its keys are, and so cannot in
good faith plead to a disgruntled customer that its systems are infallible. 
It is also significant that engineering firms do not usually share the same 
security culture as the banks, and will often have not just a higher 
turnover of staff, but of the most dangerous type of staff - young, bright 
technical specialists with the combination of curiosity and skill which can
lead to innovative attacks on security systems.

(17) A determined attacker could use parallel computing hardware to find 
the PIN key by brute force search through the set of all possible keys. Recent 
studies [A], [GO] show that such an attack would cost about \pounds 30,000 
worth of specialist computer time. It follows that such an attack is not just 
confined to government agencies but could be carried out by a reasonably well 
off private individual. It is also possible that cryptanalytic facilities in 
the former Soviet Union could be misused for private gain.

(18) Certain types of security module may cut the amount of work needed to
carry out an analytic attack. This is because the random numbers which they
generate for use as keys are often not anything like as random as the 
manufacturers claim. Security product quality has been of sufficient concern 
for the EC to introduce standards and procedures [ITSEC] for certifying all 
such products sold in Europe, but as these standards were only published last 
year, one would expect that most systems in use still fall short in some 
respects.

The symptoms of a lost PIN key might vary widely. Well organised criminals 
would presumably design their attack pattern to confuse the bank and so prolong
the time until countermeasures are taken. If the attackers were not 
particularly well organised, one would expect a steady and growing incidence 
of loss, initially in restricted geographical areas. In particular, one might 
expect PC software to be created which would work out the PIN on any card 
issued by the bank. In this case, credit and debit cards stolen in areas where 
this software was in circulation would be used in ATMs, rather than in the 
usual pattern of Switch cashouts and purchases at electrical and sports goods 
stores. Of course, banks which do not monitor disputed transactions centrally
could again be suffering large losses by the time they noticed that anything 
was amiss.

\section{Conclusions}

ATMs have been described as one of the top 100 ideas of the 20th century.
However, the security technology of ISO magnetic strip cards with PINs may be 
nearing the end of its economic life, or at the very least be due for review 
and upgrade. Recently reported figures [ST] show that plastic card fraud in the
UK was \pounds 166,000,000 in 1991, up 35\% from 1990. There will be a further
sharp increase next year, as the banks have now agreed that the customer will 
bear only the first \pounds 50 of loss for stolen cards and disputed 
transactions. This will force many losses previously borne by customers to
be recorded in the official figures. With some two million plastic cards 
stolen every year, the consequences of any large scale compromise of PIN 
security would be very serious indeed for the affected banks.

A number of prospective successor technologies are available and have been 
aggressively marketed for several years now. These include watermark cards, 
smart cards, and biometrics.

Perhaps one of the more novel developments is in the South African
homeland of kwaZulu, where Chief Buthelezi's government is using mobile voice
activated ATMs to pay pensions in rural areas. Previously, fraud by pension 
officials was a considerable source of grievance to the community, and the 
authorities for their part were suspicious of the very low mortality reported
among pensioners; now, pension cash is only dispensed after the beneficiary 
states his surname and the spectral features of this utterance are checked 
against a reference file. The system has been found to have an error rate of 
about one percent, which is an enourmous improvement on previous arrangements, 
but still not perhaps good enough for use in a developed country banking 
environment where unattended operation and 99.9\% reliability have come to be
expected.

Another biometric project is underway in India, where Nixdorf is recognising
bank customers by their fingerprints. This technology is now fairly reliable, 
thanks to decades of investment by the world's police forces, but is probably 
not acceptable in most western markets because of its criminal associations.

IBM's new cryptographic product range includes an automatic signature 
verification device. This may become a standard in future. A previous signature
based system promoted by Unisys merely stored a picture of the specimen
signature, and was vulnerable to good forgeries in the same way as manual
systems. However the new generation products such as IBM's check the signature
dynamics too, and it will be interesting to see what sort of error rates are
achieved in practice.

Watermark cards have been introduced in Scandinavia. These have a two-layer 
magnetic strip, of which the lower layer is made read-only and furnished 
with a unique serial number at the time of manufacture. This serial number, 
plus the normal strip contents, are used to calculate a cryptographic 
checksum which ensures that any alterations of the data on the strip will 
be detected. These cards offer the least change from the current card 
technology and also the lowest upgrade cost, but do not offer the system 
developer any really new options; he is still limited to a few hundred bytes 
of data storage and this severely restricts the range of applications which 
can be delivered.

Smartcards, pioneered in France, offer almost total resistance to forgery,
together with much greater on-card data storage and the ability to program
applications directly into the card itself. This gives the ability to work
off-line and may be a decisive advantage in those areas of the world which
have recently been liberated from central economic planning, and where banking
systems have to be established quickly despite the lack of a telecommunications
infrastructure. An example of a state-of-the-art system is UEPS, the Universal 
Electronic Payment System, which we designed for a French systems company 
around the GemPlus smartcard [UEPS].

In conclusion, it is high time for ATM operators to start planning the next 
generation of payment systems. There is no shortage of options, and these 
now offer the prospect that, after eight hundred years, we may succeed in 
eliminating forgery as a significant cost in the banking industry. On the 
other hand, any institution which suffers serious losses from using 
elderly and insecure technology will probably not be able to pass the cost on 
to the public. It would much more likely see its profitability, and perhaps 
even its customer base, eroded quite substantially as a result.

\begin{thebibliography}{ITSEC}

\bibitem[A]{A}
R. J. Anderson,
\newblock ``How to Break DES'',
\newblock In {\em Virus Fax International}, March 1990, pp 10 - 13

\bibitem[DP]{DP}
D. W. Davies and W. L. Price,
\newblock {\em `Security for Computer Networks'}, John Wiley and Sons 1984.

\bibitem[GO]{GO}
G. Garon and R. Outerbridge,
\newblock ``DES Watch: An examination of the Sufficiency of the Data 
Encryption Standard for Financial Institution Information Security in the
1990's,
\newblock In {\em Cryptologia}, {\bf XV}, no. 3 (July 1991) pp 177 - 193

\bibitem[ITSEC]{ITSEC}
{\em Information Technology Security Evaluation Criteria}, Provisional
Harmonised Criteria, June 1991, EC document COM(90) 314
 
\bibitem[MM]{MM}
C. H. Meyer and S. M. Matyas, 
\newblock{\em Cryptography: A New Dimension in Computer Data Security},
John Wiley and Sons 1982.

\bibitem[NSM]{NSM}
{\em Network security Module - Application Developer's Manual},
Computer Security Associates, 1990

\bibitem[ST]{ST}
{\em Sunday Telegraph}, 8 March 1991

\bibitem[UEPS]{UEPS}
R. J. Anderson,
\newblock ``UEPS - A Second Generation Electronic Wallet'', {\em to appear}

\end{thebibliography}

\vspace{3.5ex}
{\center\bf\Large Appendix - Sample Interbank Transaction}

We will now illustrate how the security module concept operates in practice by
describing a sample interbank transaction, in which our bank accepts a card
issued by a correspondent. We use the notation KA(X) to denote the data block 
X encrypted under the key KA.

{\bf Preliminaries:}

(1) Our ATM is issued with two terminal key components, KMTA and KMTB. These 
are printed in a secure room on a printer attached to the SM, and conveyed to 
the device by two trusted officials. The ATM combines them and forms its
terminal master key: KMT = KMTA + KMTB.

(2) Our SM now creates a terminal transaction key, KTT, which is encrypted 
under the terminal master key and sent to the ATM as KMT(KTT). The ATM decrypts
it and stores it.

(3) Our SM creates three zone key components ZMK1, ZMK2, and ZMK3. These are
conveyed with much ceremony to the correspondent bank and entered into their
security module, SM*, in the presence of a large number of directors, auditors
etc. SM* combines these components to form the zone key, ZMK, which it now 
shares with our SM.

(4) Our SM sends a working key, AWK, to SM*, encrypted under ZMK, that is, as 
ZMK(AWK). This operation typically takes place at the start of the business 
day. Our bank is now ready to process transactions from our correspondent's
cardholders.

(5) Each of their cardholders has meanwhile been issued a PIN which is 
essentially his account number encrypted under their PIN key, KP*, using the 
process described above. These are printed in their secure room on a printer 
attached to SM*.

{\bf Operation:}

(6) The cardholder presents his card at our ATM. The ATM reads his account and
offset data from the track, checks that the issuing bank is a correspondent,
and asks for the PIN to be entered.

(7) The cardholder enters the PIN, which is encrypted under the transaction
key and sent to our SM as KTT(PIN).

(8) Our SM decrypts the PIN. It cannot be checked locally, as we only have
our own PIN key KP, not the correspondent's KP*. So our SM reencrypts the PIN 
under the shared working key, and transmits it to the correspondent as 
AWK(PIN).

(9) SM* decrypts the PIN and checks it against the account number using
KP*.

(10) The answer, `PIN correct' or `PIN incorrect', is sent back to the 
correspondent bank's mainframe.

(11) This mainframe checks the balance available and sends an authorisation
response (basically `pay', `retry', `refuse' or `confiscate card') back through
the network. 

(12) This authorisation response is processed by our bank's mainframe,
for journalling and audit purposes, and sent on to the ATM, which dispenses
the cash, or rejects or confiscates the card, as instructed.

The above sequence of actions appears at first sight to have removed the 
risk of fraud by bank systems staff. After all, the PIN is now not known to
any employee of either bank, and neither is any key; and an outsider who is
monitoring the various communication lines has only seen the encrypted data
blocks KMT(KTT), ZMK(AWK), KTT(PIN) and AWK(PIN). 

In practice, as we have seen, current security module systems can be 
circumvented in various ways, but still do make fraud much more difficult 
than might otherwise be the case.

\end{document}