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 16 Issue 53

Sunday 6 November 1994

Contents

o UK boy cracks S.Korean system
Mich Kabay
o CMU blocks access to nasty newsgroups
Mich Kabay
o Roll-Over Date Frozen?
Ed Ravin
o Followup on Sears captures signatures
Steve Holzworth
o Minnesota driver license
Daniel Frankowski
o Re: CAPS-LOCK Considered Harmful
Jim Griffith
o RFD: sci.engr.safety
Sethu R Rathinam
o 2nd Conf. on Mathematics of Dependable Systems
Victoria Stavridou
o Info on RISKS (comp.risks)

UK boy cracks S.Korean system

"Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
06 Nov 94 15:46:40 EST
>From the Reuter newswire (94.11.04) via CompuServe's Executive News Service:

RTw 11/04 0417  S. Korea says slim chance hacker got nuclear data

    By David Brunnstrom

    SEOUL, Nov 4 (Reuter) - The South Korean atomic energy
    institute said on Friday there was a slim possibility
    a teenage British computer hacker stole secret nuclear
    data from its computer system.

    The Korea Atomic Energy Research Institute (KAERI) said
    it was investigating possible damage to its system after
    a report in the Washington Times newspaper on Thursday
    [94.11.03] which said the hacker managed to access it
    recently.

The article goes on to make the following key points:

o   "James Christy, director of computer crime investigation at the U.S.
Air Force's office of special investigations," speaking "at a conference on
global organised crime convened by Washington's Center for Strategic and
International Studies," said that "Data Stream" was a 16 year old in
Britain.

o   The youth cracked a system at the Rome Air Development Center at
Griffith Air Force Base in Rome, New York state.

o   He copied files from the "South Korean Atomic Research Institute
(sic)" to the disks on the Rome system.    [SKARI?]

o   The youth "curled up into a foetal position and cried when" the
British police arrested him.

o   KAERI officials said that technical information "such as that on
reactor systems and fuel rod design" was "stored separately from other data
and protected by multiple passwords."

o   "Chung Joon-keuk, director of public information at the
institute,....said .... it was still not clear whether the institute
referred to in the Times was in fact KAERI and it was possible the article
should have referred to the Korea Aerospace Research Institute (KARI)."

M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn


CMU blocks access to nasty newsgroups

"Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
06 Nov 94 15:46:49 EST
>From the United Press Intl newswire via CompuServe's Executive News Service:

UPn 11/04 1054 College blocks computer sex access

    PITTSBURGH, Nov. 4 (UPI) -- Carnegie Mellon University
    of Pittsburgh said Friday it will block access on its
    campus computer system to sexually explicit material
    available on the worldwide computer network called
    the Internet.

    Carnegie Mellon officials said they are acting out of
    concern that the university could by subject to
    prosecution under Pennsylvania's pornography and
    obscenity laws.

The article goes to to explain that University spokespersons admit they will
be "be accused of stifling free expression" but feel that the risks are too
high, especially since children can easily access these materials.  The
decision was said to have been difficult and painful for the administrators,
who strongly support the tradition of academic freedom.  The decision was
criticized by a student spokesperson, who compared it to banning books.

[Comments by MK:

The anonymity of the Internet will continue to cause difficult problems
related to access by children.  Right now, the response of well-meaning
administrators and others is to put blanket restrictions on everyone so as
to prevent unsupervised use of the Internet by minors.

Imagine a world where no one had developed the concept of an ignition key
for automobiles.  We can imagine well-meaning highway administrators
concerned with access to the high-speed transportation infrastructure
exclaiming, "Gosh, but with these highways and cars, children could travel
to (gasp) brothels and pigsties!  They could see things that their parents
would never want them involved in."  And so the highway administrators would
shut down roads in an attempt to prevent access to bad places by children.

In both the real world and this imaginary world, these difficulties are
caused by the lack of identification and authentication in accessing the
highways.  In the real world, we have ignition keys for automobiles and
severe penalties for stealing automobiles or driving without a permit.  We
have no accepted standards for access to networks.

Parents who are concerned about access to a network by their children could
take the responsibility of locking their computers or their modems.
However, that's a pretty crude approach too--all or nothing.  And what about
the children's independence and growth?

There are already devices available for controlling access to television;
parents program the times, channels and duration of viewing permitted for
their children, who punch in a PIN to gain personally-tailored access to the
TV.  Maybe as Internet access grows, there will arise sufficient interest
and demand for menu systems for access to the Internet.  Parents could
select the sections of the Internet which they wish to allow for their
children; children and parents could explore the Internet together and add
or remove destinations and newsgroups as they see fit.

Right now, CompuServe has access to Internet newsgroups.  The administration
has settled on a middle ground in restricting access to the Internet by
limiting the _listings_ of newsgroups.  In fact, however, if someone already
knows the name of a newsgroup, they are free to subscribe even if it isn't
listed.

I think that we have to move beyond a crude TOTAL ACCESS / NO ACCESS
dichotomy in regulating access to the Internet.  We need finer granularity
in our restrictions so that we don't infringe on the rights of adults.

A final note.  In a recent thread on the NCSA FORUM on CompuServe, there was
a discussion about whether there were mechanisms for restricting BBS and
Internet access by children.  I answered, "Yes--one is PARENTAL
RESPONSIBILITY."]

M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn (Carlisle PA)


Roll-Over Date Frozen?

Ed Ravin <elr@wp.prodigy.com>
Tue, 1 Nov 1994 13:15:13 -0500
Another one for the "date-dependent" bugs collection:

Last month, all five hundred or so Fujitsu model SRS-1050 ISDN display
phones here at Prodigy suddenly stopped their clocks at 11:59 PM September
30.  [Typoed 31 fixed.  PGN] The problem seems to be that the built-in clock
on the phone freezes when trying to roll over into the first day of a
two-digit month.  Resetting the clock/calendar to the current date and time
fixes the problem until the next month rolls around.  While the clock is in
its "stuck" state, the "message waiting" light will never go on, no matter
how many voice mail messages are waiting for you (you still get the
"stutter" dial tone, though).

These phones were newly installed in December of last year -- their EPROMS
are dated November 1993.  Apparently this bug crept in around then and has
been installed in all Fujitsu phones of that model since.  I'm told the
manufacturer will need to replace tens of thousands of EPROMs in the field
for their various business customers who have deployed these phones.  The
new EPROMs will be tested by an outside company before being delivered to
the customers.  Until then, we need to manually reset our phones on November
1 and December 1.

Previous RISKS reports of date bugs were usually overflows of 16 or 8 bit
quantities -- is this a new record in lower limits?

Ed Ravin, Prodigy Services Company  445 Hamilton Avenue
White Plains, NY 10601  +1 914 448 4737  elr@wp.prodigy.com


followup on Sears captures signatures

Steve Holzworth <sch@unx.sas.com>
Mon, 31 Oct 1994 18:44:44 -0500 (EST)
Since my original post concerning Sears now digitizing signatures when
you sign a credit card slip, bunches of people :-) have sent me Email,
either asking for elaboration on the risks involved, or adding anecdotes
of their own. I'll attempt to describe the potential risks as I see them.

Summary of previous post:

Sears in my area has recently started asking for people to sign their
credit card receipts while the receipts are on what is obviously a small
digitizing pad. Sears doesn't make it obvious that this is the function of
the device.

You can refuse to sign on the tablet. They'll probably have to
call someone first to OK it.

Potential Risks of digitized signatures:

Capturing the act of signing gives the store more information than
simply scanning a copy of a signed receipt would. In addition to the basic
image of the signature, the tablet can also effectively record stroke
information (direction of strokes, and possibly, pressure of strokes).
This is important, because given stroke information, it is almost trivial
to write a program to fake a signature with a pen plotter. Simply use
the stroke points as control points for spline curves. Said control
points can then be perturbed slightly to yield what appears to be the
same signature STYLE, without being a direct copy of an existing signature.

Of course, Sears wouldn't do anything so stupid. However, once the data is
available, a disgruntled or entrepeneurial employee could sell the data to
other parties. Let's see. Bill Gates goes to Sears and buys a screwdriver on
his credit card. How much is his signature potentially worth on the market?
Or, (for the really paranoid :-) ), some government agency, say, DEA, known
to be overzealous at times, decides to "apply" your signature to some
incriminating evidence...

I don't believe Sears (and others mentioned) can perform dynamic signature
verification on the fly. They can't possibly have that horsepower at
the terminal (at present). Even simple credit card number verification
takes 30 seconds or more. Imagine the complexities of looking up one
of N million signatures, correlating it to the new sample, then issuing
a go/no-go response in a reasonable time frame. The closest approximation
to this so far is the Apple Newton handwriting recognition. It looks in
a small (10k words) dictionary, has to be trained to your writing style
over time, and still screws up often enough to cause some headaches.
How tolerant is your customer base to having their charges denied when
they KNOW they wrote a valid signature?

More importantly, what REASON can Sears have for wanting this information?
I proposed that they can't do anything useful with it yet, so why should
we let them have it? Further, to the best of my knowledge, no credit card
provider requires card owners to supply digitized signature information
when initiating a transaction. My understanding is that, per the card issuer
agreement with the merchant, the merchant CANNOT require ANY other identifying
information, assuming they get an approval code from the card issuer.
Keep in mind, you don't even SIGN a receipt for a mail-order purchase...
Why should we let Sears et al digitize our signatures?

One limited use of a digitized signature could be to display a specimen of
your signature on POS terminal so the clerk can compare with your receipt.
Of course, that is supposedly what the signature on the back of the card
is for (among other things)...

One responder mentioned that if the customer was signing paper on top of a
tablet, it was unlikely that much information could be captured beyond
stylus pressure. This is incorrect. I developed high-end CAD software for
civil engineering and land planning for many years. All of the digitizers we
used were capable of capturing positional information through quite a number
of layers of vellum, mylar, and/or paper. This was necessary because much of
engineering work involves tracing existing maps or drawings.

Several responders stated that they had run into similar digitizers at Sears,
Service Merchandise, and others. A few stated that my example of refusing
to sign had encouraged them enough to "just say no" :-) next time.

I'm not trying to be paranoid, but I attempt to see all of the angles when
confronted with a situation as described above. I operate under the rule
that unless you can give me an extremely good reason why I should give you
some class of information about me, you don't get it. Numerous posts to
RISKS have documented how quickly and easily information about someone is
disseminated, and how difficult it is to correct misinformation, once it
gets spread. I attempt to minimize acquisition of the information as a
preemptive measure.

Steve Holzworth  SAS Institute   x6872  SAS/Macintosh Development Team
Cary, N.C.  sch@unx.sas.com


Minnesota driver license

Daniel Frankowski <dfrankow@winternet.com>
Fri, 4 Nov 1994 15:55:56 -0600 (CST)
*City Pages*, a great free news weekly here in the Twin Cities (Minnesota
USA), recently had an article [1] chock full of privacy issues and
implications of the new Minnesota driver license (not "driver's" but
"driver" on our license).  I approached the article with deep suspicions
about a new card, and came away only slightly less suspicious.

The old license has been the same for 25 years.  It has a picture, a license
number and some personal information (address, height, weight, signature,
birthdate, etc.).

  .. [O]fficials were tired of the ease with which the old card could
  be forged and altered.  In early 1990, local police officials uncovered
  a forgery ring in the Twin Cities that used fake Minnesota licenses to
  open bank accounts and pass close to $1 million worth of bad checks.

To make it harder to forge, the new card is printed in several fonts and the
location of your (digitized and stored) picture depends on your age.  For
the information age, there is a barcode with your driver license number, and
a magnetic stripe that can contain three lines of about 80 characters each,
currently slated to contain a person's full name, date of birth, and driver
license number.

The article raises a plethora of issues, some of which follow.  I have
hastily tried to put them into categories, which unfortunately overlap.

INFORMATION HANDLING RISKS

- The state government assumes that the public should trust government
agencies with these technologies.  This resulted in a lack of public
discussion or input because the government did not publicize the new
card proposal.  The article gave an example I had not heard why we
should not trust government: upon dishonorable discharge from the US
military, it assigned a code which potential employers and others
could get.  257 meant "unfitness, homosexual acts," 261 was
"psychiatric or psychoneurotic disorder," 287 was "unclean habits
including venereal disease," and 289 "unsuitability, alcoholism."

- Currently, the Driver Vehicle Services (DVS) department makes all
their information public except social security number and medical
information.  That is, registration and title info, driving records,
and the personal information from your license.  The state sells it
("provides it for a fee"), and currently has 600 online accounts
(presumably customers buying the information).  They can sort by age,
area, or size of person, for example.

- The card is a universal identifier, a notion often reviled in RISKS.

- The article mentions a national database of 7 million commercial
drivers (only truckers?) called (and operated by) AAMVANET which went
online January 1989.  It contains each person's name, date of birth,
social security number, and physical descriptors.  "It was mandated by
the federal government because truckers were getting licensed in
multiple states to avoid suspensions."  Barry Goleman is the president
of AAMVANET, Inc., a subsidiary of the American Association of Motor
Vehicle Administrators.  "Goleman says that in the future, the system
will include all drivers-- currently a total of 160 million,
nationwide."

- The license may be linked to issues unrelated to driving.  In
Wisconsin, your license may be suspended for failing to pay public
fines.  The article's example is a late book fine at the public
library.

RISKS OF SUDDENLY SWITCHING TECHNOLOGIES

- The company producing them (Deluxe Check Corporation, big in
Minnesota) promised quicker turnaround for new licenses, but their
digitizing cameras overheated, and their incompatible transmission
protocols lost about 4000 new pictures which have to be retaken.

RISKS OF MAGNETIC STRIPES

Goleman (see above) said "upward of" 22 states have magnetic
stripe-reading technology for driver licenses already.

- You, the card holder, cannot easily read the magnetic stripe to
ensure that there are no mistakes because a special machine is
required.

- Businesses could modify credit card readers to read the license
stripe "ostensibly to verify ID" and build databases of shopping
habits and personal information.

- Minnesota businesses are trying to get extra information put on the
magnetic stripe.

- A state group proposed distributing AFDC (welfare) money.  The
article hypothesized the card could be used (say) to track your
location.

Comments:

At first, I was impressed with the fact that all information in the
barcode and magnetic stripe would also be visible on the card.  In
other words, no hidden information.  However, other points listed
above drained away my relief.

I noted a fatalism about the article: it catalogued frightening
consequences without proposing solutions or interviewing privacy
experts.  This seems typical of even good journalism these days.

So are there simple guiding principles about the use of information
for a driver license?

Would it be a good idea to pass a law requiring cash machines to be
able to display (for free) any information on a magnetic stripe given
the appropriate PIN #?

How else can we solve the problems above?

1. Card Blanche, Jennifer Vogel, City Pages, Vol 16, No 725, October
26, 1994, pages 15-20.

Dan Frankowski  dfrankow@winternet.com


Re: CAPS-LOCK Considered Harmful (Massey, RISKs-16.51)

Jim Griffith <griffith@netcom.com>
Mon, 31 Oct 1994 16:05:19 -0800
>IMHO, the worst button-placement crime is one almost every
>computer manufacturer for the last 20 years has perpetrated:
>the CAPS-LOCK key on the keyboard.

This "risk" is made worse by the fact that different interfaces cause users
to hack their way back to familiarity.  We're currently having that problem
at work, because our three-member UNIX team was imported intact from a
SPARCstation shop to an HP-UX shop.  SPARC keyboards have the caps lock in
the "standard" position, while HP's stick the caps lock in the CTRL position
and the CTRL key beneath the shift key (standard PC configuration).  And
each of us have addressed this in different ways.  One user has learned the
new keyboard, one user has simply switched the internal mapping for CTRL and
CAPS using xmodmap (without relabelling the keys), and the third switched
the mapping while also moving the ESC and a couple of other keys.

The end result is that we can't use each other's machines without sacrificing
as much as 25% efficiency (UNIX and vi being as CTRL-driven as they are).
We have yet to see a case where this caused an unrecoverable disaster, but
it's surely just a matter of time.

Jim Griffith  griffith@netcom.com

  [RISKS received a ton of responses on this subject.  Sorry we can't use
  them all -- our readership would probably get totally fed up with me.  PGN]


RFD: sci.engr.safety

Sethu R Rathinam <rathinam@ins.infonet.net>
3 Nov 1994 15:32:41 -0500
        REQUEST FOR DISCUSSION (RFD) SCI.ENGR.SAFETY

Name        : sci.engr.safety
Status      : unmoderated
Distribution    : World
Summary     : Safety of Engineered Systems
Proposed by : rathinam@ins.infonet.net (Sethu R Rathinam)

Proposed Charter:

This newsgroup is being proposed as an open forum to discuss safety issues
of systems built by humans.  All aspects of safety relating to the risk of
(or actual) loss of human life, loss of non-human life and/or property fall
within this charter.  Safety issues and concerns relating to all phases in a
product's life cycle as well as discussions of Regulatory Issues and System
Safety Processes and Software issues relating to safety fall within this
charter as well.

Since various Engineering disciplines are involved, it is recommended the
subject line be a clear reflection of the subject matter.  Factual posts and
informed discussion is encouraged and speculation should be kept to a
minimum.

Rationale:

There is presently no group with a primary focus on safety, though various
newsgroups discuss safety issues within the (relatively narrow) scope of
that group.  A more focussed group for safety will help people from one
discipline have more visibility to safety issues and practices of other
disciplines.

Other:

Newsgroup line "All aspects of Safety of Engineered Systems"

Cross Postings:

  [This RFD is cross posted to many others.  Please excuse duplication.]

Voting process

This is the Request For Discussion.  There will be a 30 day discussion period
(discussion will happen in news.groups - followup is set correctly, so if you
follow-up to this message, your posting will appear in news.groups).  This RFD
may be modified incorporating suggestions, if required, during this period.  If
there is no serious disagreement, a Call For Votes (CFV) will be issued by a
third party.  The CFV will last between 21 and 31 days (as announced by the
third party vote taker).  Please follow the instructions of the vote taker when
we get to that point in time.  For the group vote to pass, there should be 100
more YES (create) votes than NO (don't create) votes AND at least two thirds of
the valid votes are in favor of creation of the group.

Sethu R Rathinam                        rathinam@ins.infonet.net


Mathematics of Dependable Systems

Victoria Stavridou <victoria@csl.sri.com>
Mon, 31 Oct 1994 21:32:54 -0800
          THE INSTITUTE OF MATHEMATICS AND ITS APPLICATIONS
     2ND CONFERENCE ON THE MATHEMATICS OF DEPENDABLE SYSTEMS (MDS 95)
             4-6 September 1995 University of York, England

                   ANNOUNCEMENT AND CALL FOR PAPERS

The construction of dependable systems, by which we mean systems providing
high levels of reliability, availability, safety and/or security, is a
problem of considerable concern to both providers and users of information
processing systems of all types.  Historically, different aspects of system
dependability (e.g. reliability and security) have been studied quite
independently, albeit that many of the goals are similar.  For example, the
notion of certifying functionality assurance levels applies equally to
reliable systems and secure systems.  In addition, users will often require
some combination of security and fail-safe operation.

The purpose of MDS 95 is to consider the mathematical aspects of the
provision of dependable systems, one goal being a comparison and possible
unification of mathematical techniques for providing safe, reliable and
secure systems.  A number of different mathematical approaches have been
taken to the overall problem, including probabilistic/statistical reasoning,
formal models of safe, secure and reliable systems and logics of
authentication and access control/privilege delegation.  Papers on all these
areas are solicited, the unifying theme being the application of
mathematical techniques to the overall dependability problem.  Hence papers
will be particularly welcome which cross-fertilise the application domains.
The conference will consider dependability for both hardware and software
systems.

PROGRAMME & PROCEEDINGS The conference will consist of three days of
presentations by contributing authors.  The programme will also include
invited lectures by prominent researchers and practitioners in dependable
systems theory and practice.  Time will be made available for discussions.
A digest of papers will be available to participants during the meeting and
the proceedings will be published after the conference.

INVITED SPEAKERS Monsieur P Chapront (GEC Alsthom, France), Professor J
Knight (University of Virginia, USA) and Professor D L Parnas (McMaster
University, Canada).

SUBMISSIONS Five copies of complete papers (in English) should be sent to
Mrs Pamela Bye, Conference Officer, The Institute of Mathematics and its
Applications, 16 Nelson Street, Southend-on-Sea, Essex, SS1 1EF, England
(Tel. +44 702 354020, Fax +44 702 354111, Email imacrh@v-e.anglia.ac.uk) by
31st March 1995.  Authors will be notified of the outcome of their
submission by 26th May 1995.  Revised manuscripts will be due by 14th July
1995.  Papers must not exceed 6,000 words in length (with full-page figures
counted as 300 words).  Each paper should include a short abstract and a
list of keywords for subject classification.  All papers will be refereed
and the final choice will be made by the programme committee on the grounds
of relevance, significance, originality, correctness and clarity.  Submitted
papers must not be published or be under consideration for publication
elsewhere in the same or similar form.

PROGRAMME COMMITTEE    Programme Chair : V Stavridou (Royal Holloway,
University of London), D Gollmann (Royal Holloway, University of London),
M Ingleby (British Rail Research), J Jacob (University of York), N Jefferies
(Vodafone Ltd), B Littlewood (City University), R Shaw (Lloyd's Register),
B Wichmann (National Physical Laboratory).

LOCATION The conference will be held at the University of York, a modern
campus built around a lake with excellent facilities.  The campus is two
kilometers from the centre of the medieval walled city of York, and 60
kilometers from the North Yorkshire coast.  The city is also well placed for
the Pennines and Yorkshire Wolds. York is very well connected by rail to
London, Edinburgh and Manchester and the nearest airports are Manchester and
Leeds/Bradford.

Please report problems with the web pages to the maintainer

Top