Text File

Subject: RISKS DIGEST 11.01 REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest Monday 4 February 1991 Volume 11 : Issue 01

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: [Clean-up on some old stuff. Card stuff still pending.] Re: Enterprising Vending Machines (Allan Meers) Re: Risks of automatic flight (Henry Spencer) Re: Voting by Phone & public-key cryptography (Evan Ravitz) Re: Random Voting IDs and Bogus Votes (Vote by Phone) (Mike Beede)) Re: Patriots ... (Steve Mitchell, Steven Philipson, Michael H. Riddle, Clifford Johnson) Re: Man-in-the-loop on SDI (Henry Spencer) Re: Broadcast local area networks ... (Curt Sampson, Donald Lindsay, John Stanley, Jerry Leichter)

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. FTP VOL i ISSUE j: ftp CRVAX.sri.com<CR>login anonymous<CR>AnyNonNullPW<CR> CD RISKS:<CR>GET RISKS-i.j<CR> (where i=1 to 11, j is always TWO digits. Vol i summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye" logs out. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

----------------------------------------------------------------------

Date: Thu, 31 Jan 91 22:21:02 PST From: allans@ebay.sun.com (Allan Meers - Sun Education) Subject: Re: Enterprising Vending Machines

USER-HOSTILE VENDING-MACHINE PROGRAMMING

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 slot-machine.

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 bar.

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 customization.

SUMMARY:

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.

------------------------------

Date: Fri, 1 Feb 91 00:52:25 EST From: henry@zoo.toronto.edu Subject: Re: Risks of automatic flight

>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

------------------------------

Date: Fri, 1 Feb 91 08:54:08 MST From: eravitz@isis.cs.du.edu (Evan Ravitz) Subject: Voting by Phone & public-key cryptography

Phil Zimmerman (prz@sage.cgd.ucar.edu (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 (eravitz@nyx.cs.du.edu)

------------------------------

Date: Fri, 1 Feb 91 12:24:07 CST From: beede@SCTC.COM (Mike Beede) Subject: Re: Random Voting IDs and Bogus Votes (Vote by Phone)

>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 vote.

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

------------------------------

Date: Fri, 1 Feb 91 09:31:15 PST From: steve@caticsuf.CSUFresno.EDU (Steve Mitchell) Subject: Re: Patriot (Leichter, RISKS-10.85)

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 designed.

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. Steve_Mitchell@csufresno.edu

------------------------------

Date: Thu, 31 Jan 91 16:09:04 -0800 From: stevenp@decwrl.dec.com (Steven Philipson) Subject: Re: Patriots: Reprogramming, SDI implications (RISKS-10.82)

Nathaniel Borenstein <nsb@thumper.bellcore.com> 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.

karn@thumper.bellcore.com (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

------------------------------

Date: Fri, 1 Feb 91 08:18:46 cst From: riddle@hoss.unl.edu (Michael H. Riddle) Subject: Re: Patriot Missile

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.

riddle@hoss.unl.edu postmaster%inns@iugate.unomaha.edu University of Nebraska, College of Law, Lincoln, Nebraska, USA

------------------------------

Date: Fri, 1 Feb 1991 07:17:20 PST Sender: Mark_Jackson.wbst147@xerox.com <mjackson.wbst147@xerox.com> Subject: SDI -> Patriot? and related topics Summary: No Way

> 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 Patriot.

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>

------------------------------

Date: Fri, 1 Feb 91 10:16:27 PST From: "Clifford Johnson" <GA.CJJ@Forsythe.Stanford.EDU> Subject: Patriots

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.

------------------------------

Date: Fri, 1 Feb 91 12:59:22 EST From: henry@zoo.toronto.edu Subject: Man-in-the-loop on SDI Cc: mjackson.wbst147@xerox.com, parnas@qucis.queensu.ca

> ... 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 henry@zoo.toronto.edu utzoo!henry ------------------------------

Date: Thu, 31 Jan 91 03:42:27 PST From: curt@cynic.wimsey.bc.ca (Curt Sampson) Subject: Re: Broadcast local area networks (Cooper, RISKS-10.84 Comments: Guru? Or charlatan?

> 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.wimsey.bc.ca curt@cynic.uucp {uunet|ubc-cs}!van-bc!cynic!curt

------------------------------

Date: Thu, 31 Jan 1991 23:28-EST From: Donald.Lindsay@GANDALF.CS.CMU.EDU Subject: Re: Broadcast local area networks are a'comin

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

------------------------------

Date: Fri, 01 Feb 91 15:58:51 EST From: stanley@phoenix.com (John Stanley) Subject: Re: broadcast LANs (Letts, RISKS-10.85)

->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.

------------------------------

Date: Fri, 1 Feb 91 17:37:29 EDT From: Jerry Leichter <leichter@lrw.com> Subject: re: Broadcast local area networks are a' comin

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

------------------------------

End of RISKS-FORUM Digest 11.01 ************************