Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!mit-eddie!think!ames!lll-tis!ptsfa!lll-lcc!well!shibumi
From: shibumi@well.UUCP (Kenton Abbott Hoover)
Newsgroups: sci.crypt
Subject: Re: ATM security (was Re: DES info wanted)
Message-ID: <3131@well.UUCP>
Date: Sat, 23-May-87 17:26:55 EDT
Article-I.D.: well.3131
Posted: Sat May 23 17:26:55 1987
Date-Received: Sun, 24-May-87 01:42:19 EDT
References: <2071@hoptoad.uucp> <599@umnd-cs.D.UMN.EDU> <5747@eddie.MIT.EDU> <294@kuling.UUCP> <1071@aecom.YU.EDU> <809@idec.stc.co.uk>
Reply-To: shibumi@well.UUCP (Kenton Abbott Hoover)
Distribution: world
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 50
Summary: Software

The determination on invalidation is done at the host.  If the programmer wants
to invalidate the card on three attempts, well, then the programmer has to
put a flag on the data record for the card.  An example: Bank Of America (who
I used to work 4) simply sends a report to the branch where your account is
and the branch personel decide whether to flag your card, or just call you
and ask what the h**l is going on.

Trivia:  The Diabold and IBM ATMs (diabolds have CRTs with 4 unmarked buttons,
IBMs say IBM on them, if not they have the cash sort of flop out of a slot and
have an open/closed sign on them) are ...wait for it... 3270 devices!  They]
actually have PF keys and the whole nine yards built-in.

Usual chain of activity in an ATM:

1) The interaction with the user, screens, etc. is done by some sort of
controller, a Series/1-type (read: VERY STUPID) machine which controls 
a whole set of ATMs.  The controller normally resides at some central location
and communicates with the ATMs over leased lines.

2) When you do a transaction, the controller tries to queue up a set of
transactions from its other ATMs.  It will either succeed or timeout. In
either case, the transactions are communicated to a 37X5 and from there
to a mainframe which runs a batch job to do the transaction.

3) Most banks cannot update the account base in real-time, so the ATM
processor (the mainframe doing the batch run, not the ATM itself) works
from a database containing last nights data corrected with todays transactions.
The transaction you actually do is simply made a memo posting and is
entered into the actual accounts system as if it were a teller withdrawl/deposit
with a note saying it was from an ATM.

MORE TRIVIA: The PIN is not a timing issue (in most systems).  Its just that
the whole transaction is usually sent to the mainframe, and that is slow going.

EVEN MORE TRIVIA: Have you ever been cheated out of money by an ATM?  If you
were it was most likely an IBM.  Go to your branch and report it, and they
(after you fill out the usual form) will credit your account.  Save the ATM
receipt, as they normally ask for it.  The IBM machines steal like theives,
and normally (like in socks in dryers) the money has simply vanished.  Diabold
ATMs miscount once in a blue moon, AND if you do a transaction that asks for
more money than is the the ATM (they dont keep track in most cases), it will
give you what it has and debit your account for only that much.

STILL MORE TRIVIA: Dont deposit cash unless it is to a Diabold ATM.  Diabold
ATMs check the deposit envelope to see if there is anything in it.  IBMs dont.
The deposit box is opened by two branch officers, and they (normally) wont
swipe cash from a Diabold, since it would be hard to claim an empty envelope.
However, an IBM machine...

(someone should really write a book on this subject)