The RISKS Digest
Volume 23 Issue 87

Tuesday, 17th May 2005

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…


Prius cars shutdown at speed
Edwin Slonim
The Downside of Wired Hospitals
Ken Knowlton
Medical Usability: How to Kill Patients Through Bad Design
Dan Jacobson
Bruce Schneier
US Government to alter RFID passport regulations
Avishai Wool
Good old-fashioned physical security
Joseph Shead
Social security number seeding
Pekka Pihlajasaari
IT forecast from Dave Patterson
Marcus H. Sachs
Car breakins using bluetooth
Andrew Nicholson
Don't blame the messenger
Paul Tomblin
Re: PDF not a good format for redacting classified documents
Bob Blakley
Re: Amtrak's Acelas
Philip Nasadowski
Martin Ward
Derek P Schatz
Train anomaly
Comair: Bound to Fail
Craig S. Bell
What Search Sites Know About You
Joanna Glasner via Monty Solomon
Re: BofA agent gives out personal information
Brent J. Nordquist
SecurID: bad compared to what?
Rick Smith
Info on RISKS (comp.risks)

Prius cars shutdown at speed

<"Edwin Slonim" <>>
Tue, 17 May 2005 13:19:35 +0300

  The U.S. National Highway Transportation Safety Administration has 13
  reports of Toyota's Prius gas-electric hybrid cars (2004 and early 2005)
  stalling or shutting down at highway-driving speeds, which Toyota
  attributes to software problems.  [Source: Toyota Attributes Prius
  Shutdowns To Software Glitch Sholnn Freeman, *The Wall Street Journal*, 16
  May 2005; PGN-ed]

I have always feared losing power, brakes and steering at high speed - with
a helpful dashboard indication of "internal error 687, please reset".  Looks
like it is starting to happen.  Of course we need to put this into
proportion - how many cars stall at high speed with a fuel blockage, or
swerve with a blowout.

Edwin Shalom Slonim,  Minols Ltd, 83 Moriah Blvd,
PO Box 7360, Haifa 31072 Israel  +972-4-826-6583

The Downside of Wired Hospitals

<Ken Knowlton <>>
Fri, 29 Apr 2005 19:29:59 EDT

"Computers are making hospitals more dangerous, new research suggests.
Computer keyboards fester with colonies of bacteria, which can easily spread
from the medical personnel who use them to the patients they treat.  Some
hospitals now have computers in every patient room, creating even more
opportunities for contamination. Researchers at Northwestern Memorial
Hospital in Chicago found that the types of bacteria commonly found in
hospitals — some resistant to antibiotics — could survive on a keyboard
for 24 hours.  Simply cleaning the computers with soap and water didn't make
a difference.  Using a strong disinfectant did kill the germs — but it also
damaged the computers.  'The difficulty with keyboards is you can't pour
bleach on them,' Dr. Allison McGreer of Toronto's Mount Sinai Hospital tells
The Canadian Press.  'They don't work so well when you do that.'  Because
it's nearly impossible to keep keyboards sterile, researchers say, the onus
is on doctors and nurses to wash their hands vigorously and often."
[Excerpted from *The Week*, 29 May 2005]

Medical Usability: How to Kill Patients Through Bad Design

<Dan Jacobson <>>
Mon, 02 May 2005 08:48:36 +0800


<Bruce Schneier <schneier@COUNTERPANE.COM>>
Sun, 15 May 2005 03:39:20 -0500

  [PGN-Excerpted from CRYPTO-GRAM, May 15, 2005
  Counterpane Internet Security, Inc.]

The United States will get a national ID card.  The REAL ID Act establishes
uniform standards for state driver's licenses, to go into effect in three
years, effectively creating a national ID card.  It's a bad idea, and is
going to make us all less safe.  It's also very expensive. And it all
happened without any serious debate in Congress.

I've already written about national IDs.  I've written about the fallacies
of identification as a security tool.  I'm not going to repeat myself here,
and I urge everyone who is interested to read those essays (links at the
end).  Remember, the question to ask is not whether a national ID will do
any good; the question to ask is whether the good it does is worth the cost.
By that measure, a national ID is a lousy security trade-off.  And everyone
needs to understand why.

Aside from the generalities in my previous essays, there are specifics about
REAL ID that make for bad security.

The REAL ID Act requires driver's licenses to include a "common
machine-readable technology."  This will, of course, make identity theft
easier.  Already some hotels take photocopies of your ID when you check in,
and some bars scan your ID when you try to buy a drink.  Since the U.S. has
no data protection law, those businesses are free to resell that data to
data brokers like ChoicePoint and Acxiom.  And they will; it would be bad
business not to.  It actually doesn't matter how well the states and federal
government protect the data on driver's licenses, as there will be parallel
commercial databases with the same information.

(Those who point to European countries with national IDs need to pay
attention to this point.  European countries have a strong legal framework
for data privacy and protection.  This is why the American experience will
be very different than the European experience, and a much more serious
danger to society.)

Even worse, there's likely to be an RFID chip in these licenses.  The same
specification for RFID chips embedded in passports includes details about
embedding RFID chips in driver's licenses.  I expect the federal government
will require states to do this, with all of the associated security problems
(e.g., surreptitious access).

REAL ID requires that driver's licenses contain actual addresses, and no
post office boxes.  There are no exceptions made for judges or police --
even undercover police officers. This seems like a major unnecessary
security risk.

REAL ID also prohibits states from issuing driver's licenses to illegal
aliens.  This makes no sense, and will only result in these illegal aliens
driving without licenses — which isn't going to help anyone's security.
(This is an interesting insecurity, and is a direct result of trying to take
a document that is a specific permission to drive an automobile, and turning
it into a general identification device.)

REAL ID is expensive. It's an unfunded mandate: the federal government is
forcing the states to spend their own money to comply with the act.  I've
seen estimates that the cost to the states of complying with REAL ID will be
tens of billions.  That's money that can't be spent on actual security.

And the wackiest thing is that none of this is required.  In October 2004,
the Intelligence Reform and Terrorism Prevention Act of 2004 was signed into
law.  That law included stronger security measures for driver's licenses,
the security measures recommended by the 9/11 Commission Report.  That's
already done.  It's already law.

REAL ID goes way beyond that.  It's a huge power-grab by the federal
government over the states' systems for issuing driver's licenses.

REAL ID doesn't go into effect until three years after it becomes law, but I
expect things to be much worse by then.  One of my fears is that this new
uniform driver's license will bring a new level of "show me your papers"
checks by the government.  Already you can't fly without an ID, even though
no one has ever explained how that ID check makes airplane terrorism any
harder.  I have previously written about Secure Flight, another lousy
security system that tries to match airline passengers against terrorist
watch lists.  I've already heard rumblings about requiring states to check
identities against "government databases" before issuing driver's licenses.
I'm sure Secure Flight will be used for cruise ships, trains, and possibly
even subways.  Combine REAL ID with Secure Flight and you have an
unprecedented system for broad surveillance of the population.

Is there anyone who would feel safer under this kind of police state?

Americans overwhelmingly reject national IDs in general, and there's an
enormous amount of opposition to the REAL ID Act.

If you haven't heard much about REAL ID in the newspapers, that's not an
accident.  The politics of REAL ID was almost surreal.  It was voted down
last fall, but was reintroduced and attached to legislation that funds
military actions in Iraq.  This was a "must-pass" piece of legislation,
which means that there was no debate on REAL ID.  No hearings, no debates in
committees, no debates on the floor.  Nothing.  And it's now law.

We're not defeated, though.  REAL ID can be fought in other ways: via
funding, in the courts, etc.  Those seriously interested in this issue are
invited to attend an EPIC-sponsored event in Washington, DC, on the topic on
June 6th.  I'll be there.

Text of the REAL ID Act:

Congressional Research Services analysis:

My previous writings on identification and national IDs:

Security problems with RFIDs:

My previous writings on Secure Flight:


EPIC's Washington DC event:

US Government to alter RFID passport regulations

<Avishai Wool>
Fri, 6 May 2005 17:18:40 +0300

Responding to fears raised by privacy advocates that new electronic
passports might be vulnerable to high-tech snooping, the State Department
intends to modify the design so that an embedded radio chip holding a
digitized photograph and biographical information is more secure.
[Source: Bowing to Critics, U.S. to Alter Design of Electronic Passports
Eric Lipton, *The New York Times*, 27 Apr 2005]
[requires registration]

On a personal (self-congratulatory) note, it seems that a recent
paper by Ziv Kfir and myself:

  "Picking virtual pockets using relay attacks on
  contactless smartcard systems"

was used as ammunition in the campaign to pressure the state
department to rethink the e-passport design.

RISKS readers may find interest in this letter from the Berkeley Law School
to the Office of Passport Policy, on behalf of an impressive list of
computer scientists and security experts, explaining what was wrong with the
previous design:

Curiously, I saw somewhere recently (I don't have the URL handy) that the
only country in the world that was ready with the (now defunct) e-passport
was Belgium(?). The US was not ready to meet its own deadline...  I bet some
people in Brussels are less than happy with the news...

Avishai Wool, Ph.D., School of Electrical Engineering, Tel Aviv University,
Ramat Aviv 69978, ISRAEL

Good old-fashioned physical security

<"Joseph Shead" <>>
Sat, 7 May 2005 14:05:02 -0500

Lost items puzzle nuclear research lab: The U.S. federal Idaho National
Laboratory nuclear-reactor research lab cannot account for more than 200
missing computers and disk drives that may have contained sensitive
information.  The computers were among 998 items costing $2.2 million
dollars that came up missing over the past three years.  Lab officials told
investigators that none of the 269 missing computers and disk drives had
been authorized to process classified information.  But they acknowledged
there was a possibility the devices contained ''export controlled"
information — data about nuclear technologies applicable to both civilian
and military use.  [Source: AP item from *The Boston Globe*, 7 May 2005,

Social security number seeding (Re: RISKS-23.85 et al.)

<Pekka Pihlajasaari <>>
Wed, 27 Apr 2005 11:28:56 +0200

Many articles documenting the risks of exposure of personally identifiable
information bemoan the possibility of compromise. There seems to be very
little quantitative information on the number of cases where the information
is used inappropriately.

If a selection of unused social security numbers were identified as probes,
these could be used by credit bureaux and other large databases as proxies
for compromise. Any use of these numbers would be positive confirmation of
breach of the related database, and an indication of the rate at which
harvested numbers are utilised. While this does pollute the datasets with
incorrect data, this provides an in-band mechanism to detect misuse. The
practise has been in use by mailing list rental companies to count the
number of times a list is used.

The low occurrence of the probes makes wholesale harvesting easy to detect
and difficult for the harvester to protect themselves against. This risk, of
course, is that the list of probe numbers is compromised!

Pekka Pihlajasaari +27 (11) 728-0899 Data Abstraction Ltd

IT forecast from Dave Patterson

<"Marcus H. Sachs">
Wed, 11 May 2005 21:53:10 -0400

"The history of IT is littered with companies that lost substantial leads in
this fast-changing field.  I see no reason why it couldn't happen to
countries.  Indeed, at the recent International Collegiate Programming
Contest of the Association for Computing Machinery, four Asian teams
finished in the top dozen, including the champion, while the best U.S.
finish was 17th, the country's worst showing ever.  If current U.S.
government policies continue, IT leadership could easily be surrendered to

[ACM President David Patterson gave testimony before a Congressional hearing
last week.  PGN]

Car breakins using bluetooth

<Andrew Nicholson <>>
Fri, 6 May 2005 11:35:08 -0700

I recently lost our rental car in one of the huge parking lots of Disney
World. The color and license plate entry on the rental car tag were
incorrect and we couldn't remember the color and we had the row wrong.

Eventually security drove us around while I pushed the "panic" button on the
remote key fob at any likely looking vehicle. Security knew roughly where
the cars were parked based on the time that you caught the shuttles. Once
we found the car that was it - no further checks.

During the search I asked about car theft from the parking lots given that
they are huge and there is little sign of security patrols etc. The claim
was that they don't have many car thefts, but they do have 4 to 5 break-ins
every day where the contents of the cars are stolen.

Here's the interesting part: every break-in in the past month had involved a
laptop with internal bluetooth. Apparently if you just suspend the laptop
the bluetooth device will still acknowledge certain requests allowing the
thief to target only cars containing these laptops.

Don't blame the messenger (Re: Blakley, RISKS-23.86)

<Paul Tomblin <>>
Fri, 6 May 2005 21:38:27 -0400

In RISKS-23.86, Bob Blakley attacks the Italian newspaper who discovered
that they could use cut and paste to see "blacked out" text as "having
allies whose press is eager to publish information which will endanger your

He's not the only one, as evidenced by the discussion in the Slashdot
article he referenced.

It's an incredible mistake to think that America's enemies are so
unsophisticated or stupid that they couldn't figure this same method out
themselves if the Italian newspaper hadn't published it.  Underestimating
your enemy is a sure way to lose.

Paul Tomblin <>

Re: PDF not a good format for redacting classified documents

<Bob Blakley <>>
Fri, 6 May 2005 12:25:03 -0500

What's most interesting to me about this is that it will undoubtedly
generate all sorts of proposals for wildly expensive and demonstrably
ineffective fixes.

My prediction is that the preferred proposals will be:

1. A proprietary mil-spec word processor which is guaranteed to delete what
it redacts, to be developed bespoke.

2. A complicated PDF file filter which searches for classified information
at specified levels and strips it out.

These would be multimillion dollar projects with a customer base of - say -
five, and would be predictably behind schedule and ineffective.

The problem, of course, arises because the appearance of the document on the
screen does not correspond to its deep structure.  However it's easy and
cheap to fix this problem.

The $100 solution would be to designate a redacted-document-release server
and configure it so that it only accepts uploads via FAX.

To get documents onto such a server, you'd need to go through the analog
hole, which would automatically guarantee that the document's appearance IS
its deep structure.  Voila.

Re: Amtrak's Acelas (RISKS-23.85)

<Philip Nasadowski <>>
Tue, 26 Apr 2005 22:49:45 -0400

Actually, Acela's problems are a bit deeper:

* The trainset was built 4 inches wider than it was supposed to.  Nobody
really knows or will fess up as to why.  as a result, it can't tilt on
trackage owned by Metro-North, which is the curviest part of the system.
Elsewhere, it can't tilt as much as it was supposed to.

* The trainsets are built to the US DOT's 'Tier II' standards, which require
strength standards roughly 5 times that of UIC (European) railcars.  The
result is an enormous increase in weight - the unpowered Acela coaches are
nearly as heavy as the TGV's locomotives (!).

* The above weight issues result in the train being unstable at running
speeds, a problem never totally solved.  In addition, the curve speeds must
be lower (because of the weight).

* TGVs use their locomotives for a large amount of the total braking on the
train (easily 33%).  Acelas can't do this because they're so heavy.  Thus,
higher use of friction braking.

* Lower curve speeds mean slowing down more after a straight run...

* And that means more, heavier use of the brakes.

* Unwillingness on the part of Amtrak and the US DOT to adopt a distributed
setup where every car is powered meant additional weight (locomotives at the
ends) and only 4 axles with regenerative braking, i.e. braking with the

The real issue is that Amtrak and the DOT insisted on a custom, untested
design based on a design concept that was out of step (180 degrees!) with
every other high speed train built in modern times.  Had Amtrak simply
purchased a modified form of the X-2000 tested here in the early 90's, we
wouldn't have this fiasco today.  Ironically, the X-2000 was cleared for
higher curve speeds than the Acela can achieve safely...

Sometimes reinventing the wheel isn't a good idea...

Re: Amtrak's Acelas (Harrison, RISKS-23.85)

<Martin Ward <>>
Fri, 29 Apr 2005 14:10:04 +0100

> It seems that old-fashioned mechanical engineering is not immune from the
> ills commonly ascribed to its software counterpart.

Of course not. Its just that when it happens in mechanical engineering, the
result is news stories, lawsuits and (usually) action taken to prevent
recurrence of the problems.

In software engineering, these problems are accepted as normal business
practices. Erdos number: 4
G.K.Chesterton web site:

Re: Amtrak's Acelas (Harrison, RISKS-23.85)

<"Schatz, Derek P" <>>
Wed, 4 May 2005 10:18:07 -0700

Lack of replacement brake parts is interesting, but what's the
computer-related risk here?

  ["Risks to the Public in the Use of Computers and Related Systems."  We
  keep stressing the importance of systems in the large.  Also, the
  maintenance problem of letting essentially all of the trains fall apart
  with no spare parts is symptomatic.  PGN]

Train anomaly

<"Peter G. Neumann" <>>
Sat, 30 Apr 2005 20:46:43 PDT

I was on a "baby bullet" train last week that goes at the same speed as the
regular trains but only stops a few times over the stretch from SF to SJose,
and "the door is closing" recording kept playing between Palo Alto and
Mountain View while the train whizzed past two stations with the door in
front of me wide open.  A conductor finally heard the repeated recording
after about 5 minutes and tried to close the door manually with no success.
I asked him if that happened often, and the answer was, with a shrug,
``Well, it does happen now and then.''

Comair: Bound to Fail

<"Craig S. Bell" <>>
Tue, 3 May 2005 17:27:44 -0700 (PDT)

Followup to the Comair incident:
*CIO Magazine* offers timeline. Stephanie Overby

The crash of a critical legacy system at Comair is a classic risk management
mistake that cost the airline $20 million and badly damaged its reputation.

What Search Sites Know About You (Joanna Glasner)

<Monty Solomon <>>
Thu, 28 Apr 2005 23:34:32 -0400

[Source: Article by Joanna Glasner, Wired.Com, 5 Apr 2005]

For most people who spend a lot of time online, impulsively typing queries
into a search engine has become second nature.

Got a nasty infection in an embarrassing spot? Look up a treatment on
your favorite search site. Obsessing about an ex? Try Googling his or
her name. Chances are the queries will unearth some enlightening

But while search engines are quite upfront about sharing their knowledge on
topics you enter in the query box, it's not so clear what they know about
you. As operators of the most popular search engines roll out more services
that require user registration, industry observers and privacy advocates say
it's become more feasible to associate a particular query with an

"You should think about what you put in that search box, because it may not
be as anonymous as you think," said Danny Sullivan, editor of

It has long been standard practice, Sullivan noted, for search sites to
employ cookies, which track activity on a computer's internet browser. But
cookies don't identify a person by name. If two people access a site on the
same browser, the cookie wouldn't distinguish between them.

However, when people provide personal information to register for services
offered by search engine companies, such as free e-mail accounts, news
alerts or personalized homepages, they're no longer anonymous.  ...,1848,67062,00.html

Re: BofA agent gives out personal information (Dickson, RISKS-23.84)

<"Brent J. Nordquist" <>>
Tue, 19 Apr 2005 07:48:53 -0500

Given that the agent is using a BofA computer application in the course of
providing service, doesn't this seem like a problem you could solve with an
expert system? Design the BofA app. to require the agent to quiz the caller
on the standard birthdate, mother's maiden name or security password, last 4
of SSN, etc. authenticators, and enter that data before *any* identifying
data is displayed back to the agent. If the agent can't see it, they can't
violate (what I hope are) BofA's policies not to disclose it to someone who
isn't authenticated.

Brent J. Nordquist <> N0BJN
Other contact information:

SecurID: bad compared to what? (McLellan, RISKS-23.86)

<Rick Smith <>>
Sat, 07 May 2005 15:27:22 -0500

Lest people discount Vin McLellan's comments about SecurID by accusing him
of being a shill for RSA, let me offer an independent observation. I made a
detailed study of token technology a few years back while working for a
competing vendor (Secure Computing, owner of the SafeWord token line) and
while writing a book on authentication technology (aptly named

First, the typical alternative to SecurID's clock-based key fobs are "event
based" key fobs, like SafeWord, in which the user must push a button to
retrieve the next one time password. The effective differences between the
two systems are minor, assuming they use comparable crypto. SafeWord tokens
are based on DES technology and 56-bit keys, while traditional SecurID
products used an internally-developed crypto algorithm with 64-bit keys.
The real difference today, however, is that the newer, high-end SecurID
products are based on AES with 128-bit keys. I don't know what key size is
used in the E*Trade token - none of the reports on this, including
Gartner's, have identified the token's key size.

Second, I agree with Vin's opinion regarding USB tokens. While I hope that
they're the wave of the future, they don't work with most of today's
authentication transactions, which tend to involve passwords embedded in web
pages. It's much easier to retrofit a web site to support a key fob's one
time password than it is to update both ends of the system to support
USB-based authentication.

Third, I agree with Vin that you can't fault E*Trade for providing a back
door so that users can still access their accounts after misplacing their
key fob. It may be lousy security, but it's what the user community needs.

Rick Smith, University of St. Thomas/Cryptosmith, Minnesota

Please report problems with the web pages to the maintainer