The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 11 Issue 01

Monday 4 February 1991


o Re: Enterprising Vending Machines
Allan Meers
o Re: Risks of automatic flight
Henry Spencer
o Re: Voting by Phone & public-key cryptography
Evan Ravitz
o Re: Random Voting IDs and Bogus Votes (Vote by Phone)
Mike Beede)
o Re: Patriots ...
Steve Mitchell
Steven Philipson
Michael H. Riddle
Clifford Johnson
o Re: Man-in-the-loop on SDI
Henry Spencer
o Re: Broadcast local area networks ...
Curt Sampson
Donald Lindsay
John Stanley
Jerry Leichter
o Info on RISKS (comp.risks)

Re: Enterprising Vending Machines

Allan Meers - Sun Education <>
Thu, 31 Jan 91 22:21:02 PST

My wife stopped at a Post Office yesterday to buy some stamps, and had a run in
with some technology.  They have a vending machine for stamps, which takes
old-fashioned paper money of up to $20 denominations.  To prevent you from
using the machine as a change machine, the bill-counter attachment is
programmed to give you change of a very limited amount, forcing you to spend
about 2/3 of whatever cash you insert.  She tried a $10 in this USPS

Not until she had put money into the bill-counter would it tell her that the
selection was sold out by saying so on a display above the selection buttons.
There were no little soldout lights by each sample like on some types of
machines, and the display would not activate until you fed some cash into this
one-armed bandit.  Worse yet, even for a sold-out selection, you had to put in
as much money as the selection costs to find out that it was sold out -
otherwise the first/only message you got was "Need $.cc more".

Fortunately the common stamps were in multiple channels - unfortunately these
were all sold out also.  So here's the rock and the hard place.  There is no
sold out lights, no display on the panel without some money, no indication that
a particular selection is sold out til you have put in enough money (which can
be up to $25.00), and NO refunds without purchase.  Additionally, you have to
spend about 70% of the cash you put in.  Goldie settled on a bunch of 15c
postcard stamps that can be used next week when the letter rates go to 29c.

The risk here is that this machine is meant to be used by the general public,
and many of them are likely to be using it for the first time.  It's operation
and behavior differ greatly from the more normal soda and candy machines,
unfortunately - with much greater amounts of cash involved than with a Snickers

The bill-collecting portion appears to be an added-on unit, with no feedback
from the dispensing unit regarding product availability until AFTER the money
part has received the purchase price for that selection.  Extra programming
added in later to prevent the machines use as a change machine (for the bus
stop outside), did not take into account sold-out selections - which should
have been checked first, with or without money.  I believe that this unit was a
retrofit on an old machine, with additional programming adding later making it
a one-of-a-kind unit which acts like it didn't get much QA on the


  No (sold out) light always on.

  No light if you push the button without money to test.

  No light even with money entered, unless the amount is enough
    for that particular selection.

  No refund without purchase.

  No tag backs, no refunds, all sales final - gotcha.

I kinda thought you would appreciate the risks of a hostile-programmed vending
machine.  Especially one that would be in an environment like a post-office,
where people wouldn't necessarilly use it every day, and with a high percentage
of first-time users, who could get skunked by the over-zealous application of
the rules.

Re: Risks of automatic flight

Fri, 1 Feb 91 00:52:25 EST
>It's ludicrous to believe that any airman would allow his pink flesh to be
>routinely thrown at the ground without some control ...

I can think of one possible legitimate motive for this, which makes it a bit
less ludicrous than it first sounds.  The way for aircraft to survive in combat
is to get as low as possible.  In a real war, with serious and capable
opposition (it is not clear whether Iraq qualifies at present), a lot of flying
would be done at altitudes circa 50 feet.  The trouble is that flying at 50ft
is very different from flying at 500ft, which is a more usual training altitude
for the USAF.  The South African air force trains at 50 ft.  So do the
Israelis.  But the USAF considers training at realistic altitudes to be
unacceptably dangerous for peacetime.  The intent might have been to get the
benefits of the low altitude without the political difficulties of relatively
dangerous peacetime training or the fearful attrition rate associated with
having to learn new basic skills while being shot at.

                         Henry Spencer at U of Toronto Zoology   utzoo!henry

Voting by Phone & public-key cryptography

Evan Ravitz <>
Fri, 1 Feb 91 08:54:08 MST
Phil Zimmerman ( (303)444-4541 ) is a computer security
consultant working with the Voting by phone foundation on public-key
cryptographic protocols used for voter authentication and privacy.  His group's
scheme would prevent the government from entering bogus votes, using the PINs
of those who had not voted at the end of the election, to use PGN's example.

For those who doubt that a PIN could not be anonymous I suggest drawing them
from a hat (perhaps using a device like we used to select gumball prizes with).
The other worries, like caller ID and wire-tapping can be avoided by simply
voting from any other phone.  I'm sure I pass a dozen a day.

Paranoia is justified, but apply it to how we vote now, as well.  Don't you
think that a government that can photograph your license plate from outer space
can install a tiny video camera that watches how you vote in a booth?

Please read our brochure (E or regular mail) before picking at a system you
don't have full info on.  Contact Phil for his ingenious cryptographic system,
or myself for the brochure (

Re: Random Voting IDs and Bogus Votes (Vote by Phone)

Mike Beede <beede@SCTC.COM>
Fri, 1 Feb 91 12:24:07 CST
>Each voter is given an id number to vote, but is told that the number is either
>positive or negative.  Suppose there are two candidates, Alice and Bob.  If the
>number is negative, a vote for Alice is actually counted as a vote for Bob.

Now suppose there are four candidates.  We give each voter a complex number X.
A vote for Alice is (1+i)X, while Bob is (1-i)X, Carol is (-1+i)X, and Ted is
(-1-i)X. For up to 16 candidates we issue each voter a quaterion, but this has
the drawback that only people with graduate degrees in mathematics are able to

I believe that phone voting is trying to solve a problem that is already solved
pretty well.  The goals are 1) make it convenient for the voter to vote, 2)
make it impossible, or nearly so, to determine anyone's vote, and 3) make it
very difficult to falsify results.  I argue that 1) is already met closely
enough that the virtual sacrifice of 2) and 3) in the vote-by-phone schemes are
not justified in the least.

Mike Beede, Secure Computing Technology Corp, 1210 W. County Rd E, Suite 100
            Arden Hills, MN  55112                            (612) 482-7420

Re: Patriot (Leichter, RISKS-10.85)

Steve Mitchell <steve@caticsuf.CSUFresno.EDU>
Fri, 1 Feb 91 09:31:15 PST
A thought on the RISKS of evaluating the Patriot system's performance:

The arguments I've heard in the digest and in the media lately seem to leave
out an important aspect of this discussion.  By pointing out numerous successes
in the Persian Gulf theater, proponents of this system, proponents of complex
weapons systems, and even advocates for SDI are now implying that ALL of their
Patriots, complex weapons systems, and SDI systems will function *as promised*.
The question here has never been whether the Patriot can shoot down rather easy
targets.  The question here (and the question in evaluating the
cost/performance ratio, practicality, and effectiveness of any weapons system),
is whether the Patriot system can function in the role for which it was

If the Iraqi's had effective ECM operating, radar busting aircraft deployed,
and were attempting coordinated attacks on these cities with maneuverable
aircraft, would the Patriot be as effective as it was designed to be?  The
results from the Persian Gulf theater are inconclusive at best.  The Patriot
system's design advantages and sophistication, the very aspects of the system
that make it so expensive, are still relatively untested in combat.  These are
the aspects of the system that have been used to rationalize it's development
and deployment costs.

If GM claimed that it's new Family Van Mk IV was amphibious, would you label it
a magnificent success just because you saw 30 of them cruise down the highway
at 50 MPH?  If all you need is a Family Van that can cruise down the highway at
50 MPH, why not save a few million and go for the Family Van Mk III that
doesn't claim the amphibious capabilities.

I do not feel that the Patriot's "amphibious" capabilities have been
demonstrated here.

Re: Patriots: Reprogramming, SDI implications (RISKS-10.82)

Steven Philipson <>
Thu, 31 Jan 91 16:09:04 -0800
Nathaniel Borenstein <> writes:
>I'm awestruck that they're willing to reprogram the Patriot [...] right
>in the middle of the war! [...]

   Wartime modification and upgrade of systems is a common and time honored
practice by military units.  Experience is gained on a daily basis and both
sides modify both their systems and tactics to make use of it.  If one can't
adapt, one is placed at a tremendous disadvantage.  It would likely be deemed
unacceptable if modifications could NOT be made in this timeframe.

>[...] Patriots may never again be as useful as they are being in this war,
>because "now that their capabilities are known, it will be trivial to
>make the next generation of missiles able to fool them.

   There are large inventories of missiles with current and relatively outdated
technologies.  The SCUD itself is considered an archaic weapon.  The Patriot
will have a place in defense against these weapons.  Patriot upgrades, both
software and hardware, will likely increase effectiveness against more advanced
threats.  Certainly current assessments of their capabilities will be of
limited usefulness in estimating future performance. (Phil R. Karn) writes:

>Even the Pentagon admits Patriots are of little use against SCUDs armed
>with chemical warheads since they would merely disperse the chemical over
>the target.  [...]

   If such dispersal were guaranteed, then the Patriot would be an effective
countermeasure.  Chemical weapons are effective only when chemicals can be
delivered with sufficient concentration.  Isolated high altitude airbursts of
the chemical containers will cause the material to disperse as it descends,
this lessening concentration and reducing effectiveness.

   One of the things we've seen with the Patriots is that some but not all
intercepts disable warhead arming.  Thus some intercepted SCUDS hit the ground
without detonating, but some explode anyway.  This has major implications for
an SDI terminal area defense against nuclear weapons for which a nuclear
near-miss may be as good as a direct hit.
                        Steven Philipson

Re: Patriot Missile

Michael H. Riddle <>
Fri, 1 Feb 91 08:18:46 cst
Until about a year ago, my brother worked for Teledyne Brown Engineering in
Hunstville, on contract to the Army Ballistic Missile Division.  He claims
credit for a small part of the SDI technology that was retrofit to the Patriot,
although for obvious security reasons will not say more.  He has confirmed,
however, that SDI technology was used in some of the follow-on modifications to
both the Patriot missile itself (rocket motors) and the command/control radars
and software.
University of Nebraska, College of Law, Lincoln, Nebraska, USA

SDI -> Patriot? and related topics

Fri, 1 Feb 1991 07:17:20 PST
> The [Patriot] system was contracted for 15 years ago by the Redstone
> Arsenal.  It was initially to be an anti-aircraft missile, and it still
> is, but about four years ago, unspecified software upgrades on the ground
> equipment and hardware upgrades on the missile's detonation fuze were
> made so that the system willa also be able to destroy tactical missiles,
> such as the Russian Scud.

> Various news organizations have alluded to or asserted outright that the
> upgrades are technologies developed under the Strategic Defense
> Initiative program.  "That is bull!  There is no 'Star Wars' hardware or
> software in Patriot," [Redstone Arsenal public affairs officer David]
> Harris said.  "There has been no 'Star Wars' funding of Patriot.  This is
> all Army."  He said the SDI Organization is planning to provide $40
> million for continuing development of the Patriot's advanced seeker
> (nose-cone radar), but it has not been received by the Army yet.

This from "Portrait of a Patriot" by Brian Santo.  Unfortunately I have no idea
where this appeared; the clipping was posted in our coffee room this AM and I
have been unable to run down the source!  However, the technical content is
high and consistent, so I am inclined to believe that the foregoing is a true
reflection of the [US Army Missile Command's version of the] history of the

The article *does* assert that "[t]he missile itself has its own radar. .
.which kicks in as it nears its target," but the description of operation is
otherwise consistent with Henry Spencer's recent posting (RISKS DIGEST 10.85):

> Even Patriot's homing is actually controlled by the ground computers; the
> missile itself has no brains to speak of, just a receiver system that
> picks up radar reflections off the target and relays them to the ground
> for assessment

so possibly a passive radar was meant but not explicitly stated.  On the other
hand, if SDIO sees an application it seems more likely that the Track Via
Missile (TVM) radar is active, not passive.

Finally, in the same message Henry remarks

> I've never understood why it is fundamentally impossible to put "man in
> the loop" for space-based systems.  I'd be interested in seeing this
> explained. There is clearly a serious shortage of time for
> decision-making, but the same is true of terminal defence against
> tactical missiles -- which have much shorter flight times than ICBMs --
> and short-notice decision-making in combat is both possible and
> practical, as any fighter pilot can testify.

I'd say alertness.  Crews, even highly-trained fighter pilots, need time to
come up to combat-readiness from standby.  Note that in the current case of
"terminal defence against tactical missiles" (Santo again)

> [t]he detection and firing sequence is entirely automatic, and the only
> intervention required of a human operator is to stop the Patriot from
> firing.

This kind of tripwire arrangement looks unacceptable, at least for boost phase.
I suppose one could quibble over the the use of the word "fundamentally," but
*I* wouldn't want to have to design a robust system of this type.

Mark <MJackson.Wbst147@Xerox.COM>


"Clifford Johnson" <GA.CJJ@Forsythe.Stanford.EDU>
Fri, 1 Feb 91 10:16:27 PST
Henry writes:
> The recent incident of an accidental launch against
> aircraft is silly as a test case, since the Patriot system
> reportedly was in antimissile mode and thus probably wasn't
> expecting evasive action.

It would seem that this mistake exhibited a flaw in the antimissile software
design, though further details are needed for confirmation.  Namely, there was
no effective software check of observed radar track for ballistic trajectory.
A launch against returning planes should have been precluded by a simple
trajectory test.

Man-in-the-loop on SDI

Fri, 1 Feb 91 12:59:22 EST
> ... one could quibble over the the use of the word "fundamentally," but
> *I* wouldn't want to have to design a robust system of this type.

The question, of course, is whether one can design a better system
without humans involved, where "better" includes not just probability
of functioning well when desired but probability of functioning when
not desired.  If you compare fallible, inattentive humans against the
Pentagon's imaginary perfect computers, then of course you conclude
that the man-in-the-loop system is inferior.  Against real computers
running real software, I'm not so sure.

                                         Henry Spencer at U of Toronto Zoology

Re: Broadcast local area networks (Cooper, RISKS-10.84

Curt Sampson <>
Thu, 31 Jan 91 03:42:27 PST
> From: Brinton Cooper <abc@BRL.MIL>
> Subject: Re: Broadcast local area networks are a'comin (Tom.Lane, RISKS-10.83

Brinton Cooper <abc@BRL.MIL> writes:

> the risk for spectral chaos seems to be quite high.  Imagine the RFI
> (radio frequency interference) implications of a central city full of
> wireless ethernets(tm?) attempting to coexist with cellular phones, [etc.]

Interference will only be had by devices operating on the same frequencies.  If
the networking system is given its own band of frequences it won't interfere
with cellular phones any more than FM radio does.

There are other risks to this scheme, though.  Ethernet is based on a collision
detection scheme.  If two nodes send out a message at the same time they detect
the collision (because the data is scrambled) and then wait a random amount of
time before retrying the send.  It would be relatively simple to build a small
box which would output a short burst of RF every few milliseconds.  The more
often this box "squawked" the more collisions it would create on the network
and the slower the network would get.  Generate these pulses often enough and
you could bring the entire network to a halt.  The box would certainly be able
to operate for several days powered from a normal nine volt battery, and would
be small enough to hide easily.

Now what if several major financial firms relied on wireless networks in their
office and I decided that I wanted to create a little chaos and impede their
ability to respond on the morning of a large takeover bid?  Simply drop by for
a "visit" and toss one of these boxes in a nearby garbage can.   curt@cynic.uucp    {uunet|ubc-cs}!van-bc!cynic!curt

Re: Broadcast local area networks are a'comin

Thu, 31 Jan 1991 23:28-EST
I'm not familiar with Apple's proposal, but I am very pleased with Motorola's
WIN (Wireless In-building Network) proposal.

WIN is to use 10 MHz channels within the 18-19 GHz band, and this has some very
special propagation characteristics.  Each "microcell" network can ignore
another network's use of the same channel, 120 or 200 feet away - less if a
concrete floor or wall intervenes. (Unlike infrared, 18 GHz can pass through
drywall and partitions.)

The system uses "low power" (I don't have a number).  It also uses a fair bit
of multiplexing and packetizing, with source/destination pairs changing at 1
MHz. But best of all, 18 GHz reflects off walls, causing a considerable
multipath problem (ie multiple out-of-phase copies of the signal).  Some very
clever design was required to allow in-cell reception at all: things should be
pretty well incoherent, a very small distance away. WIN is probably as secure
as the office suite it's in.

Don     D.C.Lindsay .. temporarily at Carnegie Mellon Robotics

Re: broadcast LANs (Letts, RISKS-10.85)

John Stanley <>
Fri, 01 Feb 91 15:58:51 EST
->Reading the notices about the approach of broadcast LAN's reminded me of a
->semihumorous incident that happened about 2 years while I was doing some
->consulting for a "local" oil company.  ...

->All of the remote telemetry units were communicating with the
->master station computer via low power Johnson radios, and I had made sure that
->we had dummy loads on all of the antennae so as to cut down the range of the
->transmissions.  This screwed up SWR's and about everything else,

    Dummy loads are designed not to screw up the SWR's. They are a
perfect match, unless you are using the wrong dummy loads. Somehow, in
this case, that wouldn't surprise me. But I quote this section as
anecdotal evidence that the system was not licensed for data
communications work.

->Sporadically, we would get bursts of errors for seemingly no reason, and then
->good comm again for a while.  ...

->Much to my surprise, I heard
->some poor fella in a delivery truck complain about "there's that doggone
->buzzing sound again" to his dispatcher at the same time that our comm
->efficiency dropped to zero!

   This is quite humorous. Ha. And quite lucky that you were not
using radios that just happened to be tuned to the hospital or other
emergency frequency. But you were probably saved by using radios that
were licensed for business band voice communications, so all you screwed
up were all the other users of that frequency.

->It was kinda fun listening to all of those guys swear at the strange
->interference that they were getting.

   Yes, many sick people DO find it quite a hoot to cause deliberate
interference to licensed users of the spectrum (and the moment you
identified the source of the interference to YOU, you became deliberate
interference to the pizza service). I don't think the FCC feels like it
is a fun game. They tend to levy fines on people for doing it.

re: Broadcast local area networks are a' comin

Jerry Leichter <>
Fri, 1 Feb 91 17:37:29 EDT
Two responses to points raised by some recent messages on this issue:

    1.  Ian Clements is concerned about possible effects on medical
        devices such as implanted heart monitoring devices.  All
        thing are possible, but there are already TONS of transmit-
        ters out there.  This is hardly a new or poorly understood
        problem.  However, note that a broadcast LAN, designed to work
        over a 150 foot radius, is likely to use much lower power than
        a cellular telephone, which must work over many miles.

    2.  Rich Rosenbaum comments that some of these technologies use
        spread-spectrum techniques, hence may be inherently secure.
        Well, yes and no - but mainly no.  There are several different
        spread-spectrum techniques, but let's take a simple one,
        frequency hoping.  In this technique, we select a broad
        channel - say 100Mhz wide.  We consider it to be subdivided
        into 100 1Mhz-wide slots.  Traditionally, we then parcel those
        slots out to 100 users.  In frequency hoping, we instead
        send signals on ALL the bands.  Each "channel" corresponds to
        a sequence of slots spread over the entire channel.  The
        sender hops through its sequence at a rapid rate - say, it
        switches every millisecond.  The receiver follows the same
        sequence of slots, synchronized with the sender.  A receiver
        that follows some other sequence has only a one in a hundred
        chance of intercepting the signal at any given time.  So a
        receiver listening on a a "channel" receives very little junk
        from any given unrelated channel.  It's possible to choose a
        large number (<> 100) of different "channels" (sequences) such
        that any subset of, say, 20 transmitting hardly interfere.
        This means that you can have many more than 100 users on the
        channel, who can almost always get through (unless too many
        want to do so at once).

        Now, if you don't know the particular sequence the sender is
        using, you have a hard time reading his message.  In fact,
        it's not even easy to tell that he's sending!  The acronyms in
        use to describe this stuff include LPD/LPI/LPE (Low Probabili-
        ty of Detection (enemy can't even tell you are there)/Inter-
        cept (enemy knows you are sending but can't extract any signi-
        ficant features of the message)/Exploitation (even if the
        enemy can "read" your signal, he can't tell what it means)).
        The flip side of this is AJ, Anti-Jam (i.e., jam-resistant).

        However, keeping the sequences secret complicates the system.
        It's much simpler to use fixed, pre-assigned, publically known
        sequences.  What's traded off is the protection the modulation
        technique COULD provide.  In the case of a broadcast LAN, LPD
        and LPI are of little importance; what you care about is LPE.
        If you were to use strong, secret sequences, you'd get those -
        but the hardware needed (which must generate a cryptographic-
        ally strong sequence of slot numbers) is comparable to the
        hardware you'd need to do encryption, and you'd still have to
        add all sorts of stuff to complete the system:  You can use
        the same key safely on a lot of different messages, but you
        can never safely re-use a hop sequence (so there's a whole
        synchronization problem to solve).

                            -- Jerry

Please report problems with the web pages to the maintainer