| University of Bielefeld - Faculty of technology | |
|---|---|
|
Networks and distributed Systems
Research group of Prof. Peter B. Ladkin, Ph.D. |
|
| Back to Abstracts of References and Incidents | Back to Root |
| This page was copied from: http://catless.ncl.ac.uk/Risks/16.07.html | |
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Crossover of Diagnosis and Procedure Code creates risk
The Italian Crackdown?
Umass/Amherst Suffers From Week-long Service Degradation
More on the A300 crash at Nagoya on 26 April 1994
Palm-reading and immigration
Computer-based Notice Boards and Emergency Information
Re: Killers sue over phone taps
Revision to the Secure Hash Standard
Automated address changes
Re: Tandem and California DMV
Tracking
Secret... not so secret [NYNEX PINs]
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
I work at a local HMO, Harvard Community Health Plan, on evenings and
weekends. When we see patients, we get a printout of the recent visits by
those patients, along with diagnoses, major and minor problems, medications,
etc. HCHP uses a 4 character code for most of these, consisting of a letter
followed by 3 numbers (for example, O991 is a headache). However, the same
code can mean different things in different areas. I saw one chart that had a
diagnosis of Chronic Lymphocytic Leukemia, which is odd as an isolated finding
in a young adult. Curious as to how this devastating diagnosis got on this
persons chart, I did some looking, and finally found that the same code was a
procedure code for the administration of a particular vaccine, but it had been
cast as a diagnosis instead. I alerted the patient (and medical records) to
the problem, since otherwise I could see this person being denied life
insurance in the future.
Obviously, identical codes should not mean different things in different
fields.
Paul Stoufflet, Decision Systems Group, Brigham and Women's Hospital
75 Francis Street, Boston, MA 02115 pstouffl@dsg.harvard.edu (617) 732-7746
[notes in brackets are mine. - mech@eff.org]
Forwarded message:
Date: Mon, 16 May 1994 12:29:14 +0200 (MET DST)
From: Fabrizio Sala <fsala@varano.ing.unico.it>
Subject: The Italian Crackdown??
To: BBS-L@SAUPM00.ing.unico.it
Cc: eff@eff.org
Hello. I'm the Sysop of one of the BBSs in Italy.
I'm writing this message in this list to inform you, the BBS community, of
what is going on in Italy.
Some days ago, starting from Pesaro (Italy), our Police started a large
perquisition through [inquisition against] many Amatorial [amateur] BBSs,
mostly connected to the main networks (One for all: Fidonet... but also
PeaceNet and many others)
They're getting everything they can find: computers, monitors, drives, hard
disks, floppy, cdrom, streamer tapes ... everything, without looking if they
are or not in any way "illegal" ...
Generally, every network in Italy is now full of holes... and many of us lost
everything "in the name of the anti-piracy"...
Nobody of us is doing anything in any way illegal, but they are still getting
everything...
They got more than 50 BBS and Police's work is still going on...
I hope that everyone diffuses this message ... or in any way tells everybody
what's going on ...
...and if you have any way to help us...please do it! We made our best to
make the Italian telecommunication scene working... they are killing us!
See you later... if they don't get me!
______ end fwd ______
Stanton McCandlish * mech@eff.org * Electronic Frontier Found. OnlineActivist
Date: Mon, 16 May 1994 09:09:11 -0500
From: Jonathan_Welch <JHWELCH@ecs.umass.edu>
Subject: Umass/Amherst Suffers From Week-long Service Degradation
Newsgroups: comp.dcom.telecom
X-Telecom-Digest: Volume 14, Issue 229, Message 4 of 14
After slightly over a week of unreliable phone service things returned to
normal and the following appeared in the May 13th edition of "The Campus
Chronicle".
Jonathan Welch VAX Systems Manager Umass/Amherst JHWELCH@ecs.umass.edu
- - -
Telephone system returned to normal
As you know, the University had a major problem with the campus telephone
system which began last Monday, May 2. The symptoms of the problem included
calls being cut off, static, a "fast busy" tone when calling on campus and
telephones without dial tone. The symptoms were sporadic and fairly random for
both academic/administrative telephones and residential telephones.
As soon as the problem started, Ericsson, the manufacturer and maintainer of
the telephone system, responded. Ericsson staff worked straight through from
Monday morning to late Thursday evening to diagnose and remedy the problem. In
addition to the normal three on-site technicians, Ericsson brought in staff
from their regional headquarters in Northboro, and flew in a high level
technician/ system programmer from the Technical Assistance Center in Cypress,
Calif. They also had programmers in Cypress and Sweden working remotely to
stabilize the system and to determine the cause of the problem.
The problem with the system resulted from a unique set of circumstances
involving software parameters, system clocking and a normal maintenance
procedure performed on the system. The problem was exacerbated by the
increases of load on the telephone system we have experienced this year.
The campus telephone system is a complex, distributed computer. Such systems
are designed with a great deal of redundancy and can self-correct for many
faults. Once the problem occurred, parts of the system were continually
trying to reset themselves. In this instance, the complexity of the system and
its attempts at self-correction made it difficult to trace the problem and
stabilize the system. By Wednesday afternoon, Ericsson had made substantial
progress in correcting the problem. They made a configuration adjustment in
the system and implemented a slight but important programming change in the
software. This adjustment, while straightforward, was difficult to install on
the system because of the heavy call volume on campus and the size of the
campus system (18,000 lines on 119 system modules). What Ericsson
accomplished is analogous to fixing an electrical problem in a car traveling
down the highway at 50 miles per hour. The parameter they adjusted did not
initiate the problem, but the change allowed the system to return to normal
operations.
By early Thursday morning in the residence halls and noon on Thursday in the
academic/administrative area of campus, service had considerably improved.
Except for a brief interruption of service while circuits were being tested,
calls in progress were no longer interrupted by static or cut off. There may
have been some problems completing a call or placing long distance calls while
work was in progress. However, in general TelCom was quite successful at
assisting individuals in making their long distance calls. Ericsson has made
adjustments in the system configuration, system clocking and maintenance
procedures to ensure that this problem will not recur. I realize the telephone
service problems last week were very frustrating for everyone. Telephone
service is an important part of our daily lives and any interruptions or
degradations in service are a very serious problem. I truly appreciate the
patience of the campus community while we struggled to deal wilh the problem.
We in TelCom, as well as the Ericsson staff, were even more frustrated (if
that is possible) at not being able to get the problem resolved quickly. We
apologize for the difficulties and will work closely with Ericsson to prevent
this problem from occurring again.
Randy Sailer, director, Telecommunication Services
On 26 April, a China Airlines A300-600 crashed on landing at Nagoya airport,
killing 264 people. The crew had announced they were `going around' (aborting
the approach and gaining altitude to come back for another landing attempt),
but continued the approach. Near the ground, the aircraft pitched up (raised
its nose in the air), stalled, and `hit the ground at a high rate of descent,
tail-first and completely stalled'. (Flight International, 11-17 May 94, p5).
Part of what is known so far is that the Flight Director or FD (a form of
autopilot) was in `go-around mode', and the co-pilot was physically trying to
counteract the guidance of the FD, specifically against published procedures
(FI, op. cit.). The FD, trying to fly up with the co-pilot commanding fly-down
on the elevator, counteracts with nose-up trim (the horizontal stabilizer at
the tail is repositioned by the pilot or by the FD so as to maintain a desired
attitude of the aircraft, climbing, cruising, or descending, simply by
aerodynamic equilibrium. This is called `trim').
At 700 ft, both autopilots are disconnected. The aircraft pitches up steeply
because full nose-up trim has been applied (this cannot be overcome by
control-column input alone -- pilots must readjust trim). At 540 ft, the
anti-stall system triggers full power, which gives additional pitch-up moment,
and the aircraft enters a very steep climb with a pitch of 36 degrees. The
pilots fail to readjust trim. At 980 ft, a pilot selects flaps-up to go-around
setting causing a pitch-up to 52 degrees, and a speed decay from 124kt (slow)
to 78kt (disastrously slow) (FI, op.cit.)
To give an idea, light planes stall (their wing ceases to provide lift) when
the angle of the wing to the `relative wind' (the airflow vector considered
relative to the wing of the aircraft) becomes roughly 15 degrees. Transport
aircraft are similar, but I don't know the stall angle of the A300-600 wing in
landing configuration.
The Japanese Transport Ministry's Aircraft Accident Investigation Committee is
also looking into an apparent loss of all electrical power moments before the
crash. The chairman, Manabu Matsumoto, has `no recollection of a case like
this, an apparent failure of all power'. (International Herald Tribune, 11 May
94 p2).
Features of this accident of potential interest to RISKS readers at this point
are (a) the preliminary confusion of the crew about which control mode was
selected on the autopilot; (b) the full nose-up trim consequence of the
interaction between the co-pilot and the FD; (c) the autopilot triggering
full-power and therefore a high nose-up moment when the nose was already high;
(d) the apparent failure of all power.
One should be cautious if trying to `second guess' the accident investigation.
Airplanes such as this are meant to be flown a certain way, in which pilots
are thoroughly trained. Pilots are generally legally required to hold to those
procedures except in case of emergency.
Peter Ladkin
In the May 12 Financial Times of Canada, there is an article entitled "How
palm-reading can speed your way into the U.S."
=-=-=-=-=-=-=-=
Put your hand up if you've had it with the interminable lineups to pass
through airport immigration checkpoints when travelling to the United States.
That upraised hand could be your ticket to zipping right through.
The U.S. Immigration and Naturalization Service (INS) is testing a new
system that turns your hand into the only piece of identification you need
to bypass immigration officials ans skip right through customs, cutting up
to 45 minutes off the procedure for heading south.
Called the INS Passenger Accelerated Service System (INSPASS), it works
like this: a three-dimensional image of your hand is electronically
recorded on a white, plastic, wallet-sized card. You run the card through
a scanner, place your palm onto an electronic reader and, as long as your
hand and the card match, you're issued a computer-generated receipt that
opens a gate arm, sending you past immigration officials to custom
inspection.
[Summarizing the next few paragraphs, INPASS is being tested at three
sites: Pearson (Toronto), JFK, and Newark. The article goes on to explain
registration at INS offices, which takes about 10 minutes and is free
during the indefinite test period. Open to citizens of Canada, Bermuda,
Japan, New Zealand, most of Europe and the U.S., but have to make at least
three business trips per year to qualify.]
Concerned about privacy? Sally Jackson, director of public affairs for the
Offices of the Information and Privacy Canada, says you shouldn't be. The
only people participating are those who consent to putting their hand
impression on the card; besides, no other record of the hand image is kept.
So far, 26,502 people have signed up for INSPASS, including 2,764
Canadians. More people, no doubt, will follow when they realize how, uhhh,
handy the system is.
=-=-=-=-=-=-=-=
What happens if the systems does not recognize your hand? I'm curious as to
the recognition rate. For example, if you get married after registering, will
a ring throw the system for a loop?
Also, I find it interesting that the image is kept on the card only. Will
the INS keep a record of your travels? (Or do they already?)
John Oram oramy92@halcyon.com Victoria, BC Canada
RISKS-16.05 and -16.06 included discussion of problems with cable-TV
notice-generation systems crashing and leaving cryptic or amusing error
messages for all to see ("Amusing computer-related anecdote about local cable
service," Long, Jones, Hrisko). Failures and usability problems with such
computer-driven notice boards can sometimes have more serious consequences:
My father lives in a retirement community in a high-rise building. While I
was visiting there recently the building's fire alarm went off. My father
immediately said, "Turn on the TV -- channel 8."
The building's cable system includes a local notice-board channel that
typically shows screens rotating through the dining room menu, daily
events, and so forth. It's also used for emergency notices.
Sure enough, within a few seconds, the notice channel stopped showing the
lunch menu and switched to something like:
The fire is on the 75th floor.
Please follow the directions of your floor warden.
(Evacuation procedures apparently differ according to location above or
below the fire floor.) The problem with this notice is that the building
has only 24 floors!
Evidently someone in the management office soon realized the error.
Everyone in the building was then treated to several minutes of
cursor-dancing around the screen, as that person tried, unsuccessfully, to
change the notice. A cursor would move around the screen, closing in on but
failing to select the floor number; the screen would switch to a Master
Menu Page and back to the fire notice again; more vain attempts would be
made to select the floor number; back to the Master Menu; and so on.
Finally things remained static for several minutes. "Aha," said I, they've
gone to get The Expert." Sure enough, when screen activity resumed the
floor number was immediately changed to a reasonable one, just in time for
the all-clear. (It was a false alarm, as are most of the alarms in that
building, but that's a different RISK.)
Electronic notice boards in public or semi-public settings can be used for
things other than routine bulletin-board postings. If they're going to be used
for getting across emergency information, then the same requirements for
usability under stress and that we'd expect for other safety-critical
applications apply to them, too. We'd also expect that users of such systems
ought to be thoroughly trained for emergencies, but system design ought to
allow for situations where a not-so-thoroughly-trained user is all that's
available.
John R. Gersh (John_Gersh@aplmail.jhuapl.edu)
The Johns Hopkins University Applied Physics Laboratory
Mich Kabay complains about criminals wanting their 4th amendment
rights preserved. If the state wants to wiretap their conversations, odds are
good that a judge could be convinced of probable cause. The fact is these
wiretaps are warrantless, and should be replaced by wiretaps authorized by
warrant. I've also yet to hear of criminals (outside of Congress) who want to
deny others rights they claim for themselves.
There are several clear risks in denying someone all of their rights
because of a conviction. They include false convictions, a growing disregard
for the Constitution, and the moral problems of punishments being chosen by
prison officials/cops, rather than the judicial system.
Adam Shostack adam@bwh.harvard.edu
The following notice was released by NIST a couple weeks ago, but
doesn't seem to have made it to RISKS yet.
No additional information is available regarding the nature of the "minor
flaw." I called NIST and the NSA when the announcement first came out, but
was told that details of the problem were confidential. They also didn't know
when a revised version would be available.
It will be very interesting to see whether non-NSA cryptographers find the
problem...
Paul Kocher, Data security consultant kocherp@leland.stanford.edu
(The following bulletin is available via anonymous FTP at csrc.ncsl.nist.gov
as pub/nistnews/sec_hash.txt)
--- Begin Included Message ---
April 22, 1994 Contact: Anne Enright Shepherd
(301) 975-4858
MEDIA ADVISORY
NIST ANNOUNCES TECHNICAL CORRECTION TO SECURE HASH STANDARD
The National Institute of Standards and Technology today announced it
will initiate a technical modification to a computer security standard used to
support the authentication of electronic messages. The revision will correct
a minor flaw that government mathematicians discovered in a formula that
underlies the standard.
The Secure Hash Standard, adopted as a federal information processing
standard (FIPS 180) in May 1993, can be used for computing a digital signature
and remains a highly secure way to ensure the integrity and authenticity of
data used in electronic mail, electronic funds transfer, software distribution
and data storage applications. NIST expects that products implementing the
current standard can be used until the technical correction becomes effective.
Researchers at the National Security Agency, who developed the formula
and discovered the flaw in a continuing evaluation process, now believe that
although the formula in FIPS 180 is less secure than originally thought, it is
still extremely reliable as a technical computer security mechanism. The
discovery of this flaw indicates the value of continued research on existing
and new standards.
The Secure Hash Standard specifies a secure hash algorithm for computing
a condensed representation of a message or data file. This 160-bit condensed
message "digest" represents the original message and can be used in computing
a digital signature to authenticate the integrity of the message. It is
highly probable that any change to the message after it has been signed will
result in a different message digest, and the recipient will not be able to
verify the signature. Signing the message digest rather than the whole
message usually improves the efficiency of the digital signature process.
It is very highly improbable that today's computation equipment can
figure out any message that corresponds to a given message digest.
The standard applies to agencies of the federal government for protecting
unclassified information when a secure hash algorithm is required. Private
and commercial organizations have been encouraged to use this standard on a
voluntary basis. The SHS was designed to be used with the proposed Digital
Signature Standard, which is based on the digital signature algorithm and has
not yet been approved.
As a non-regulatory agency of the Commerce Department's Technology
Administration, NIST promotes U.S. economic growth by working with industry to
develop and apply technology, measurements and standards. NIST also is
responsible, under the Computer Security Act of 1987, for developing standards
and guidelines for the cost-effective protection of unclassified federal
computer systems.
National Institute of Standards and Technology, Public Affairs Division
Admin. A903, Gaithersburg, MD 20899-0001
--- End Included Message ---
Recently I've had a problem with incoming mail to my home address. A few
months ago, mail started arriving (late) with just the wrong zip code and
sometimes with the wrong town name too. The incorrectly addressed mail was
usually magazines and junk mail but when credit card bills started arriving
(or not arriving) with the wrong address it was time to investigate.
My wife checked at the local post office and they said that this was a problem
for the whole zip code; the whole town had been affected. The post office
officials had no explanation as to how this might happen. They explained that
it our responsibility to correct those who have the wrong address.
The more important ones were corrected over the phone, although it was
sometimes difficult to convince the operator that we hadn't moved, the address
had spontaneously changed.
Whatever generated the wrong address is still at work. After getting the mail
addressed correctly for a few months, the wrong address would reappear.
The post office's solution to this problem is to print bar-coded labels with
the correct zip code and stick them to the mail. Mail is now arriving on
schedule even with the wrong address.
I've all but given up on correcting the wrong addresses.
I'm guessing that some address verification service shipped a data base with
the wrong zip code for our town. (I wonder how many other towns were
affected?) Some mailers just updated the zip code and others trying to get a
canonical address used the new (wrong) zip code to determine the town name.
Recently a bit ran in risks about the California DMV computer upgrade fiasco;
the original story mentioned Tandem Computers in a poor light. I'd just like
to point to a reference on the World-Wide Web to Tandem's official statement
on the issue, at <http://www.tandem.com/press-releases/dmv.html>. Also, a
copy of the California Legislative Analyst's report on the topic is online at
<http://www.tandem.com/press-releases/cla-dmv.html>; there is a hyperlink to
this latter item from within the first document.
Claimer: Tandem is my day job. DisClaimer: I am not an official spokesperson
for Tandem; one such is however listed in the dmv.html document.
Scott Hazen Mueller scott@zorch.SF-Bay.ORG or (tandem|ub-gate)!zorch!scott
[Thanks. The original item was in RISKS-15.80. Actually, the item noted
the DMV position that neither the software vendor nor the hardware maker
were responsible. Of course, the consulting firm was fired from the job.
PGN]
"There is something a little eerie about picking up a car phone and having
a voice describe your location to within a few feet on a pleasant if
unremarkable street of colonial and tudor-style houses."
That's a quote from a second article in the New York Times promoting the Avis
project to track the company's rental cars through GPS hardware and wireless
communications. The full reference is:
Peter Marks, For a few lucky motorists, guidance by satellite, New York
Times, 2 April 1994, pages 1, 16.
The reporter apparently went for a ride with the system, and was enthralled.
No doubt it was a fascinating experience. This article does at least mention
privacy concerns, in a parenthetical note, as follows:
"On the Nynex computer screens, the cars show up as small dots moving along
the roads on the computer maps. Nynex officials say, however, that for
the sake of privacy, a car's position will only show up on a screen for the
duration of a driver's call to the Project Northstar number."
Note that "privacy" only extends to what's presented on the operator's screen.
Nothing is said about the more fundamental issue, what records are stored in
the computer.
Phil Agre, UCSD
[EDUPAGE:]
> A sweepstakes promotion sponsored by Nynex-owned New York Telephone used
> replicas of customers' calling cards, including their secret personal
> identification numbers, or PINs. The mailing has caused an uproar among
> some of the three million recipients, who worry about unauthorized use of
> their calling cards. Nynex has offered to change the PINs of customers who
> complain and cover any fraudulent charges. (New York Times 4/7/94 A1)
What's wrong with this picture? Well, changing the PINs only of customers who
complain is a bad plan -- what if I didn't see the ads and don't know I should
change my PIN?
Giving out real data (even card #s, let alone PINs) to a 3rd party (the ad
agency) is another bad plan.
Not treating customer data as secure is a third bad plan; it's especially
galling since NYNEX sends out these little reminder cards to customers telling
us not to divulge our PIN to anyone.
Speaking of galling, how "generous" of them to cover fraudulent charges. As
if they didn't already do this. It's a fancy way of saying "we're not going
to do anything about this."
The thing that particularly strikes me is that it appears NYNEX is, once
again, treating this as a special case. This is a particularly annoying RISK
we see over and over again, where incidents are treated as aberrations and the
symptoms are treated with no thought given to the structural problems which
caused them.
I have no idea how to counteract this particular RISK, except by target
educating the relevant people, assuming we can find them.
--Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard
Media Lab - Advanced Human Interface Group wex@media.mit.edu 617-258-9168
[Also noted by wb8foz@netcom.com (David Lesher). PGN]
| This page was copied from: | http://catless.ncl.ac.uk/Risks/16.07.html |
| COPY! | |
| COPY! | |
|
by Michael Blume |