The RISKS Digest
Volume 11 Issue 49

Friday, 19th April 1991

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…

Contents

University library security, or lack thereof...
Marc Andreessen
Re SB 266 (cryptographics)
A. Padgett Peterson
Trap doors and such
Robert Hartman
Senate 266; Personal Privacy
Rob Boudrie
S. 266
David A. Honig
David Chase
Re: Accident statistics continued (Seduction of the innocent)
Mike Jones
Re: Simulation: Minus heart disease
David Alex Lamb
YABCWS (Yet Another Boy Crying Wolf Story)
Joe Morris
Consumer Privacy article: Consumer's Reports, May 1991
Jon B
Re: Automated car parking?
Stephen R. Smoot
Louis Koziarz
Brian Smithson
Scott Hinckley
Re: Drive-by-wire
Brad Templeton
Info on RISKS (comp.risks)

University library security, or lack thereof...

Marc Andreessen <andreess@mrlaxs.mrl.uiuc.edu>
Thu, 18 Apr 91 20:33:19 -0500
At the risk of taking space away from the very interesting current threads in
RISKS, I'd like to relate a very interesting administrative procedure practiced
at the University of Illinois.

The U of I library, like most other university libraries, is completely
computerized; terminals in each of the three-dozen departmental libraries, as
well as other terminals in residence halls and a dedicated telnet port on one
of the university's Unix systems, allow anyone to browse through the
12-million-book collection AND check out any available book.

Now, this is mighty convenient for us busy students and researchers.
Unfortunately, this is also security-free.  From a terminal or telnet
connection, one can check out a book merely by giving one's university ID
number (which, at Illinois, is always one's SSN).  Then, one can go to the
appropriate central or departmental library (where library staff regularly
retrieve books from the stacks to match computer charge requests) and say
something like ``I charged out a book called _The Adventures of Foobar the
Dancing Bear_ a couple of hours ago,'' upon which the librarian will cheerfully
hand you the book in question WITHOUT CHECKING YOUR ID, since the charge has
already been processed by the central computer.

Obviously one is free to use whomever's ID (aka SSN) one pleases.
(Incidentally, when I checked out a book this afternoon from our Engineering
Library, the librarian had the book in hand when he suddenly looked at me
suspiciously and asked, ``What's your ID number?''  I rattled it off.  He
checked it against the computer printout and, satisfied, gave me the book.)  Of
course, the minimum fine for a nonreturned book is $50, which - like an overdue
fine - is automatically billed to one's Student Accounts Receivable.
                                                                        Marc

Marc Andreessen___________University of Illinois Materials Research Laboratory
Internet: andreessen@uimrl7.mrl.uiuc.edu____________Bitnet: andreessen@uiucmrl


U.S. Senate 266, Section 2201 (cryptographics) (RISKS-11.43)

A. Padgett Peterson <padgett%tccslr.dnet@uvs1.orl.mmc.com>
Fri, 19 Apr 91 11:05:53 -0400
Bill Murray writes:

>The referenced language requires that manufacturers build trap-doors
>into all cryptographic equipment...

While the language appears to provide access to law enforcement agencies,
the effect will be to simply drive all US manufacturers out of the crypto
business. The reason people and companies buy secure communications equipment
if for secure communications. The reason they buy a particular manufacturer's
device is because it satisfys the requirement (quantum) and is at the lowest
available overall cost (linear) or provides some other advantage (may be
either). If the quantum requirement is not met by one device/method, another
will be chosen (in this case, none is a choice).

DES became a standard because it was considered to be adequate and devices
using it were cost-effective and fast. Should such a bill pass, the market will
simply turn to other solutions. PCs make alternatives easy and a true code
could be considerably more difficult to break than the DES.
                                                                Padgett


Trap doors and such (Leichter, RISKS-11.48)

Robert Hartman <rhartman@thestepchild.sgi.com>
Fri, 19 Apr 91 20:05:02 GMT
Actually, I don't think there's anything to debate.  If it is technically
possible to create cryptographic systems that a government cannot break, people
will create them and people will use them.  Governments most of all.

A government can only slow the process by which they become more widely used.


Senate 266; Personal Privacy

Rob Boudrie <rboudrie@encore.com>
Fri, 19 Apr 91 14:29:49 EDT
Although US citizens have a right against self incrimination, it is unlikely
that this right extends to withholding cryptographic keys encoding potentially
embarassing or incriminating information.  The courts would likely hold that
you can be forced (under threat of being jailed for contempt of court) to
disclose the keys to your files, much the same way you can be compelled to
produce possibly embarrassing or incriminating paper files without violating
the right of protection against self incrimination.

So what is the concerned individual or business to do?

Establish a well documented, and publicized, policy of encoding numerous
"dummmy files" (perhaps using man pages as source text) using your standard
encryption algorithm, with random keys which are not recorded.  This will
produce a *DOCUMENTED SITUATION* in which you are not able to product
decryption keys for the majority of your files, even if you wanted to.

[Of course you'd better check with your attorney first - any action
 designed to make it more difficult to penetrate your veil of privacy may
 be illegal.]

Rob Boudrie       rboudrie@encore.com


S. 266 Query

"David A. Honig" <honig@ics.uci.edu>
Thu, 18 Apr 91 18:24:54 -0700
Suppose that the strongest sense of the bill were law: no one could sell
crypto equipment that the government couldn't  crack.  Ok, the government
regulates trade, so they can do this.

But could they prevent public-domain sharing of code that accomplishes
the same?  It would seem that sharing information freely is protected
by the constitution.  Shareware couldn't be construed as "obscene", even
in the most backwards parts of the Carolinas...

Would the "national interest" cries be listened to, even though the Soviets (or
Panamanians or Iraqis or dope capitalists or whoever) surely are aware of
superior, if expensive, encryption methods (eg, 100 bit DES or 1000 bit RSA)??


S. 266

David Chase <David.Chase@eng.sun.com>
Fri, 19 Apr 91 12:24:02 PDT
I'm a little curious if there will be any point to this bill at all in a few
years.  It burdens the service and equipment providers with the reponsibility
of permitting the government access to the plain text, but that seems to leave
a gaping hole between the modem and my fingers and mouth.  Is my
Amiga/Macintosh/Next/PC/Sun "electronic communications equipment"?

A few notes that might be relevant here — the basic patent on RSA encryption
must be running out in a few years, because they published their method in
April 1977.  Seventeen years from then is April, 1994 (plus one for the US
patent grace period is 1995).  The most recent issue of _Computer Architecture
News_ (March, 1991) contains an article describing a 200Kbit/second, 512 bit
key, RSA encryption and decryption implementation (the implementation used
three "Programmable Active Memory" boards).  One can only assume that the
hardware required to implement this will get cheaper in the future.

Public key encryption also has the delightful property that the sender need not
know how to decrypt the message sent; you can hand all your keys and equipment
to the Authorities, and the most that they can do is spoof your messages.
Sounds to me like the horse is out of the barn and long gone.

David Chase, Sun


Re: Accident statistics continued (Smee, RISKS-11.45)

Mike Jones <mjones@fenway.aix.kingston.ibm.com>
Fri, 19 Apr 91 14:12:02 -0400
There is a risk here which is facilitated but not caused by computers. This
study appears to be prone to the "Seduction of the Innocent" fallacy. This
book, written by one Dr. Frederic Wertham in the 1950's, propounded comic
books as the root of all evil based on the high correlation between juvenile
delinquency and comic books - i.e., about 95% of J.D.'s read comic books.
The omitted information was that about 95% of *all* young people read comic
books at the time. I wonder, in this survey, whether the items quoted above
mean that drivers who described themselves as above average are more likely
to have accidents, or that drivers who have many accidents are more likely
to describe themselves as above average - the relationship is *not*
commutative!

Mike Jones, AIX Development, Kingston, NY             ibmps2!aix!mjones


Re: Re: Simulation: Minus heart disease (Cooper, RISKS-11.47)

David Lamb <dalamb@avi.umiacs.umd.edu>
17 Apr 91 13:44:21 GMT
An interesting point; increasing speed can increase the risk of not thinking
about what you're doing.  I've heard at least one netflamer say he'd like to
have an option on his mail that automatically delayed sending it for a few
hours, then asked him if he'd really still like to send it.  There's an old
science fiction short story by Cyril Kornbluth (possibly co-authored; my
collection is 500 miles away) called something like "Education among the
Camiroi", where one of the educators' goals was to *reduce* students' reading
speeds, so they'd get better comprehension of the material.

David Alex Lamb             internet: dalamb@umiacs.umd.edu


YABCWS (Yet Another Boy Crying Wolf Story)

Joe Morris <jcmorris@mwunix.mitre.org>
Fri, 19 Apr 91 16:11:46 EDT
With all of the complaints RISKers have about systems which can acquire data
about users' financial situation without telling the customer, we need to
remember that the notifications sent by a properly-designed system must be both
timely and correct.  This morning's mail included an example of a notice which
fails the test.

I've had an American Express card for several years; the only basic change
which has been made to the account in this time has been an address change
eight years ago, and an *involuntary* change in the bank which services the
Express Cash feature.  This bank change occurred last June (ten months ago)
because the original bank no longer participated in the program.  Without
offering other options AX reassigned the account to its internal bank (American
Express Centurian Bank).

The notice I received this morning was a prepackaged self-mailer; the note
inside had a check against the box which said "[This is a] confirmation of the
change you requested in your enrollment in the Express Cash program."  It did
not say what that change was; it didn't even have a place for that data.

Since I hadn't asked for any changes I called AX at the number on the notice
(bonus points to AX for printing the WATS number).  After talking to six people
and listening to the usual elevator music, I was told that:

(1) the notice was generated because someone at Centurian had changed the
    routing symbol used in processing bank transactions,

(2) I should ignore the notice, and

(3) I was being very unreasonable in complaining about being sent a spurious
    notice that an unrequested change had been made in my account.

Clearly someone's program is generating this mailer if *any* of the base
account information block changes, even if the change originated completely
within the vendor, and the change was in internal control information.

AX deserves credit for trying to notify its customers of changes made to their
accounts, but the outright hostility I encountered in trying to chase down the
reason for the notice worries me.

The law, in both the US and elsewhere, seems to be moving in a direction which
places significant liability on credit vendors for damages (real or imagined)
caused by bad data.  (Not far enough IMHO.)  Over the years RISKers and other
professionals have expressed concern about the posting of incorrect,
misleading, out-of-date, or just plain fraudulent information in customer
credit files.  I suggest that at the same time that we push the issue of making
sure that the customer knows what has been put into the data base that we need
to strongly pressure vendors not to play the central character in the old fable
of the boy who cried "WOLF".
                                           Joe Morris


Consumer Privacy article: Consumer's Reports, May 1991

<JONB@FAIR1.BITNET>
Fri, 19 Apr 91 10:04 EST
In the latest issue of Consumer's Reports (May '91, pp 356-60), there is
an excellent article on the consumer credit databases on what appears to be
90% of adults in this country. These databases are regularly shared or sold
to targeting advertisers, or referenced during loan/credit card/insurance
applications. There are statistics on errors, examples of damaging mistakes,
and addresses for contacting to minimize the availability of your files.

For instance, to get a copy of your file that insurance companies and doctors
seem to be able to reference upon request, write to the Medical Information
Bureau, P.O. Box 105, Essex Station, Boston, Mass 02112. The information
provided may not be anything interesting or damaging (or legible, for that
matter) but can stop you from getting insurance for seemingly unapplicable
reasons.

To get a copy of your "credit rating information" you must write to all three
of the major credit bureaus. The report you receive will contain mistakes and
none of the reports from the three of them will match. Furthermore, they will
all be impossible to understand. Write to:

        Eqifax
        P. O. Box 4081
        Atlanta, GA, 30302
        (404) 885 8000

        Trans Union
        East:   P.O. Box 360
                Phillie, PA 19105
                (215) 569 4582
        Midwest:Consumer Relations
                222 S First St, Suite 201
                Louisville, KY 40202
                (502) 584 0121
        West:   P.O. Box 3110
                Fullerton, CA 92634
                (714) 738 3800

        TRW Credit Data
        National Consumer Relations Center
        12606 Greenville Ave
        P.O. Box 749029
        Dallas, TX 75374-9029
        (214) 235 1200 x251

To reduce the number of legitimate direct mail marketing you receive, by making
your database unavailable (to the scrupulous), write to:
        Direct Marketing Assn
        11 W 42 St
        P.O. Box 3861
        New York, NY 10163-3861

As an aside, the book seems to indicate that these places don't make it easy,
since they have no problems when your database is incorrect. If you stick you
nose out, they might start giving you a hard time. Good way to ensure that
everyone remains a sheep, I think.

A book is recommended called "Privacy in America" by David F Linowes, by
University of Illinois Press.
                                                Jon


Re: automated car parking? (RISKS 11.47)

Stephen R. Smoot <smoot@postgres.Berkeley.EDU>
Tue, 16 Apr 91 18:50:07 -0700
In RISKS 11.47, alayne@geas.gandalf.ca (Alayne McGregor) writes:
> The representative said the car is a test prototype built by Volkswagen of
> America. It can sense whether a parking space is large enough, and place itself
> in the spot with only inches to spare on either side. The driver does not need
> to be in the car.

Adding a not-so-new, but increased, RISK of being the poor person whose
old-fashioned car becames sandwiched between two new Volkswagen's which can
park "with only inches to spare."

And even worse, their fate as the cars become more and more common, causing
city planners to decrease the size of parking spaces.  Which makes the
situation even more likely...


Re: automated car parking?

Louis Koziarz <lnk10562@uxa.cso.uiuc.edu>
Wed, 17 Apr 91 00:22:47 -0500
>The representative said the car is a test prototype built by Volkswagen of
>America. It can sense whether a parking space is large enough, and place itself
>in the spot with only inches to spare on either side. The driver does not need
                       ^^^^^^^^^^^^^^^
Gee, that's nice.  So you can park in relative peace and come back to find
the guy with the beater in front of you has repeatedly bashed in your front
bumper trying to get out.  Thanks, but no thanks...

Louis Koziarz      University of Illinois Urbana/Champaign    koziarz@uiuc.edu


Re: automated car parking?

Brian Smithson <brian@motcsd.csd.mot.com>
18 Apr 91 02:47:30 GMT
I saw a similar demonstration of a prototype from another manufacturer (can't
remember which) on Motorweek '91 (PBS).

>I wonder who would be liable if the car software bashed the next car while
>parking, or if it ran over a cat, dog, or child on its approach. One would
>think the location and range of the sensors would be very important.

This one has, as I suspect the VW does too, four wheel steering.  Four wheel
steering allows the car to be parked with very little space between it and the
adjacent cars.  What I wondered was how the poor sap behind or in front of such
a car would get out?  Suppose someone puts their brand new '96 VW in front of
my '72 Galaxie and leaves me 2 inches of clearance.  I wouldn't be worried
about the *software* causing some dents! :-)

Brian Smithson, Motorola Inc., Commercial Systems Division, 10700 N.DeAnza Blvd
Cupertino, CA 95014 USA, (408)366-4104 {apple | pyramid}!motcsd!brian


Re: automated car parking?

Scott Hinckley <scott@hsvaic.boeing.com>
18 Apr 91 14:36:13 GMT
I have always wondered about another risk this poses:
   assume these are marketed
   assume there are no new parking zones made
   assume you in your non-self-park car get blocked in by two self-parked
Now, how in the heck are you going to get out if there are just a few inches in
front and back of you?

This would perhaps necessitate the creation of self-park-only zones.

<<<<<<<<<<<Scott Hinckley<<<<<<<<<<<<><><><><>>VW&Apple][Forever!!!<><><><><>
Internet:scott@hsvaic.boeing.com|UUCP:...!uunet!uw-beaver!bcsaic!hsvaic!scott


Re: drive-by-wire

Brad Templeton <brad@looking.on.ca>
Thu, 18 Apr 91 17:12:37 EDT
I have serious doubts that we will see such a system for some time — not
until we are truly forced into it.

People simply refuse to tolerate death by computer error.  It seems they
would gladly take ten times the amount of death by human error first, or
death by their own error.

Any computerized traffic system would have some bugs, and thus some deaths.
But even if traffic deaths are reduced from 10,000 to 100, and likewise for
injuries, the problem is that a computerized traffic system creates somebody
else to blame, other than yourself and the other drivers.

Lawsuits will seek out the vendors.  Every accident in the automatic system
will mean a costly lawsuit — possibly millions of dollars — for the vendor
of the cars and systems, as well as the operators of the roads and the traffic
authorities.

Our current system depends on the fact that most people never get properly
compensated, or that the compensation is spread out among thousands of drivers
and their insurance companies.   To concentrate it all in a few parties, even
at a level orders of magnitude less, is probably more than any firm can bear.

People feel they are in control on the road.  Even if somebody else causes
an accident, they like to feel they might have the power to avoid it with
sharp driving.

This is sad, and perhaps the greatest RISK (in terms of loss of life) ever.
Tens of thousands of people are killed and more are injured by auto accidents,
and this system could make a dramatic reduction in this.  We have the
technology now to do it, but we won't for some time because of fear of
computers and litigation.

Please report problems with the web pages to the maintainer

x
Top