The RISKS Digest
Volume 2 Issue 23

Thursday, 6th March 1986

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


o Computerized voting
Jeff Mogul
Larry Polnicky
Peter G. Neumann
o ATM Ripoff
Dave Curry
o Internet importance/robustness
Tom Perrine
o Info on RISKS (comp.risks)

Computerized voting

Jeff Mogul <>
5 Mar 1986 2307-PST (Wednesday)
    From: <T3B%PSUVM.BITNET@WISCVM.WISC.EDU>  (Tom Benson)
    Subject: Computerized Voting

    After the election, a representative random sample of precinct boxes
    would be counted by hand, and matched to the electronic tally, just to
    audit accuracy.

I'm afraid of the seeming reasonableness of this "solution".  If we are
using the audits to look for fraud in ballot-counting, then "who chooses the
`representative random sample'" becomes the interesting question; votes,
unlike decaying nuclei, are not uniformly distributed.  People who tend to
vote for candidate X might live in certain precincts (i.e., black people);
might vote at certain times of day (9-to-5 working people); might vote by
absentee ballot (older people).  If I had the ability to "cook" a voting
machine, I might just as easily have the opportunity to cook the "random
audit selector".

If we are using the audits to detect failures, rather than fraud, then we
must still check every machine and for all times of day, for the same
reason: to avoid disenfranchising a segment of the electorate, whether
inadvertently or intentionally.  Every vote counts: recall the senatorial
race in NH decided by 1 or 2 votes a few years ago, or (closer to where I
now live) the East Palo Alto incorporation election, decided by 13 votes and
still being challenged in the courts.

Another thing: mikemcl@nrl-csr (Mike McLaughlin) suggests
    The "receipt" would contain the date, time, machine number, serial
    number of the vote, and name the candidates and issues for or
    against whom/which I voted.  It would NOT list my name.

No, but the poll watcher who saw you vote and wrote down the machine
number and time of day next to your name wouldn't have much trouble
matching the receipt, if you ever returned it.

I'm not saying that non-computerized systems are immune to error;
but be careful that a technology that appears value-neutral (such
as "representative random sampling") isn't ignoring political reality
or creative dishonesty.

Computerized voting

Thu, 6 Mar 86 08:11 MST
I find the various suggestions to back up computerized voting with
physical ballotting as taking steps in the wrong direction.  Certainly
we can reduce risks by backing up computer/automated systems with human
beings, where feasible, but to keep around a bunch of punched cards in
order to ensure the integrity of electronic voting seems to me to be the
wrong approach.

Larry Polnicky, Honeywell Information Systems, McLean, Virginia.

Computerized voting

Peter G. Neumann <Neumann@SRI-CSL.ARPA>
Thu 6 Mar 86 17:33:34-PST
This is not a VOTIVE message; I have broken my vow to remain silent while
watching the schemes for voting integrity get wilder and less controllable.
DEVOTED as I am, I can no longer keep silent.  My main point here is that as
more complex mechanisms are added to control or audit the integrity of the
voting process, the more vulnerabilities are likely to be introduced, and
the less controllable the whole process is likely to be.  Nancy Leveson
makes a similar point in her survey paper on software safety: as complexity
is added to control safety, the more things get out of hand.  I am prompted
to drag out my old Albert Einstein quote — for our newer readers:

  Everything should be made as simple as possible, but not simpler.

There is intrinsic complexity in the voting process.  A voting scheme with
no controls is easy to misuse.  A voting scheme with many controls can also
be misused, but in different ways — perhaps requiring greater subtlety.
Furthermore, such a computerized system must be used and administered by
ordinary mortals; however, elaborate procedures tend to break down or be
vulnerable.  Furthermore, remember that many of the programs controlling
elections are written by just a few software houses.  The potential for
Trojan-horsing around is enormous.  A gifted system programmer can pull off
all sorts of things.  We have already seen cases of data changed on the fly
in computer-counted ballots, even with consistency checks and audit trails
(which themselves can be fudged).  One can dream up all sorts of checks and
balances — formal verification of the algorithms, crypto seals on the
stored code for integrity, encryption schemes to detect added ballots, and
so on, but there are always points of vulnerability.

So, in the discussions here, please let us try to be realistic!


ATM Ripoff

Dave Curry <davy@purdue-ecn.ARPA>
Thu, 6 Mar 86 08:59:55 EST
   WASHINGTON (UPI) - A computer glitch enabled a man to get away with
$140,000 in $10- and $20-bills in a weekend run on 16 automatic teller
machines in the nation's capital and its Virginia suburbs, the Secret
Service said Wednesday.
   Michael Caputo, 31, of Fairfax Station, Va., admitted in federal
court Tuesday to using a stolen VISA credit card to make more than 400
withdrawals from the money machines last October.
   The withdrawals represent the largest fraud committed agains VISA
with an automatic teller machine, officials said.
   "Why didn't someone else in line notice it?" asked John Magaw, a
Secret Service agent.  "It's very bizarre.  All of a sudden this guy
realized how good he had it.  His pockets just weren't big enough.
The machines just weren't programmed to stop."
   Caputo was photographed by monitors at the 16 mechanized tellers
receiving $300 during each transaction - at times smiling while other
times holding bags of money.
   "Normally, you can't take more than $200 at a time, and (most
machines) will not allow you on nights and weekends to go beyond a
certain limit," Magaw said.  "Somehow, the safeguards broke down to
allow for that to happen."
   Magaw said that Caputo apparently used the VISA card at two banking
institutions.  He said that the two computers did not "blend together,"
and allowed him to take large amounts of money without being detected.
   "It's like having a Chevrolet and a Buick and putting a carburetor
from one on the other," Magaw explained.  "You may get it to work, but
it just doesn't quite go together.  There's glitches that have to be
worked out."

He emptied the machine of several thousand dollars, put it all into a
paper bag, and left.  The next day he went to the main office of the
bank, saw the manager, and said, "Your teller machines can be robbed."
The manager of course said this was impossible, at which point my
friend dumped the bag of money on his desk and said, "You won't be
wanting this back, then."  The machines were down for the next several

Anybody have some stats on these things?  I seem to recall seeing
something that the banks are still losing money on them, but it didn't
show any figures.  Anyone have any data on this?  I'm sure that given
a few hours most people on this list could come up with at least one
way to rob the machine down on the corner.... (let's not discuss the
methods in detail though; I'm sure the banks have enough problems
without us advertising ways to steal from them).

--Dave Curry

   [I have various inside stories about the extent of fraud, but the
    victimized institutions seem to keep pretty quiet.  They don't want to
    lose customer confidence and customers.  Besides which, they can simply
    up the rates to amortize the losses.  Who cares, especially if the
    customers don't even know?  (OK.  I care.)  PGN]

Internet importance/robustness

Tom Perrine <tom@LOGICON.ARPA>
6 Mar 86 16:50 PST
The following message, which was in the tcp-ip list from SRI-NIC was in
discussions of Internet (ARPA/MIL) Mailbridge performance.  I think it is
interesting from a RISKS point of view.  How much does the computer
science, aerospace, etc industry/research depend on the Internet?? What are
the consequences of a long-term failure of ARPAnet? How suceptable is the
ARPANET to terrorism/natural disaster/etc. ?
  >Date:  3 Mar 1986 17:03:11 EST
  >From: Edward A. Cain <cain@EDN-UNIX.ARPA>
  >Subject: Re: Mail Bridge Performance
  >To: gross@mitre.ARPA (Phill Gross)
  >Thanks for the summary of mailbridge traffic. I think it does partially
  >explain why performance is so awful at times thru the mailbridges. The
  >correlation with school schedules is interesting, too, and probably a better
  >guess than any I've heard recently.
  >There is one other important consideration. Performance on the ARPANET alone
  >has been terrible at times. For example, ICMP ECHO and ECHO REPLY round-trip
  >measurements between east and west coast hosts were averaging 18 seconds on
  >Feb 3-4, with tails of the delay distribution out to 37 seconds, as measured
  >from DCEC (via arpanet) and at BRL (via milnet). Delays were very high
  >again during the Feb 12-14 time period. Even worse, on Feb 20th, one hour
  >in the afternoon the roundtrip delay from DCEC to the arpanet interface of
  >the ISI mailbridge was 30-40 seconds, and from DCEC to the arpanet
  >interface of the SRI mailbridge the delays were 45-47 seconds during the
  >same hour, with 90% packet loss!!!
  >Usually, this kind of behavior on the arpanet is coincident with the outage
  >of key lines or nodes in the arpanet. On Feb 20th for example, line 76
  >(utah to lbl2) and line 76 (sri2 to collins) were both down most of the
  >day because of flooded cableheads.!!! The loss of a key component in the
  >arpanet seems to create serious congestion when the traffic goes up. And
  >congestion is noticed quickly by the mailbridges, which are among the
  >busiest arpanet hosts in terms of both packets sent and connection blocks
  >used (in the IMP).
  >Ed Cain

The recent message about flooded cableheads and the potential vulnerability
of the internet to loss of critical components made me wonder:

  How many IMPs are there on the ARPA side?                  [Hundreds]

  How many on the MILNET side?                               [Hundreds]

  Where are they? I would assume that at least the MILNET IMPs are
  in secure areas.          [Not necessarily, but they are under the
                             control of DCA and BBN.  That helps.  PGN]

Tom Perrine

Please report problems with the web pages to the maintainer