Mon, 16 May 1994 13:03:15 -0400 (EDT)
[notes in brackets are mine. - mech@eff.org]
Forwarded message:
Date: Mon, 16 May 1994 12:29:14 +0200 (MET DST)
From: Fabrizio Sala
Mon, 16 May 94 20:56:51 -0500
Date: Mon, 16 May 1994 09:09:11 -0500
From: Jonathan_Welch
Peter Ladkin
Fri, 13 May 1994 21:24:17 +0200
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
John Oram
Sat, 14 May 1994 17:53:38 -0800
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
John R. Gersh
Mon, 16 May 1994 10:29:07 -0400
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
Re: Killers sue over phone taps (Kabay, RISKS-16.06)
Adam Shostack
Mon, 16 May 1994 15:10:55 -0400
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
Paul Carl Kocher
Mon, 16 May 1994 02:48:15 -0700
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 ---
Linus Sherrill
Tue, 10 May 94 15:19:40 EDT
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.
Scott Hazen Mueller
Sat, 14 May 94 21:20 PDT
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]
Phil Agre
Tue, 5 Apr 1994 15:31:31 -0700
"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
"Alan (Miburi-san) Wexelblat"
Fri, 8 Apr 94 12:16:59 -0400
[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]
Report problems with the web pages to the maintainer
Crossover of Diagnosis and Procedure Code creates risk