The RISKS Digest
Volume 15 Issue 47

Wednesday, 9th February 1994

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

"Sounding the Alarm: Noisy medical alert systems"
B Fitler
(Semi-)electronic locks
Pete Kaiser
Safety in Telescript, Part Deux
Luis Valente
Risks of email exacerbating typos
M. Hedlund
Patents Hearing as it relates to Software
Paul Robinson
Network surveys et al.
Steve Holzworth
Re: Don't Trust The Phone Company
Lars Poulsen
Re: "Misunderstanding" a CERT advisory
D.R. Newman
Re: Clipper Petition
Pete Kaiser
John Mainwaring
Re: Altered White House Documents
Firth
Larry Nathanson
EFF Wants You (to add your voice to the crypto fight!)
Stanton McCandlish
Info on RISKS (comp.risks)

"Sounding the Alarm: Noisy medical alert systems"

<bfitler@ccmail.com>
Tue, 08 Feb 94 19:05:55 pst
Article titled "Sounding the Alarm: Noisy medical alert systems are
getting out of hand" by Jon Van, Chicago Tribune, appeared in San Jose
Mercury News Science & Medicine Section 8 Feb 1994.

The article pointed out the alarm systems from medical equipment are
"driving doctors and nurses to distraction" who agree that "alarm noise
pollution is a significant problem that threatens patient health"
presumably because "doctors order that all alarms be disconnected except
those deemed absolutely necessary for patient safety."

Points raised in the article:

* Efforts to create international standards for alarms have been
underway since 1983 and are still unfinished.

* "...it is common for one event, such as a drop in a patient's blood
pressure or speeding of his heart's rate, to set off a cascade of alarms
from several sources..."

* "... conditions change during surgery, and medical equipment isn't
able to distinguish context..."

* "... typically the attorney or chief executive [of the medical
equipment manufacturer] thinks that the louder the alarm, the less
likely their company is to be sued if someone doesn't respond..."

* Manufacturers see legal problems in trying to tie together warning
systems from a variety of medical systems.

The article did not point out the technical difficulties involved in
prioritizing alarm conditions.


(Semi-)electronic locks

Technology Strategy & Architecture <kaiser@heron.enet.dec.com>
Wed, 9 Feb 94 08:18:15 MET
The "New Scientist" for 6 February 1993 contains this article:

        Chips hold key to door security

    An electronic key with a chip in its tip is to be marketed by the
    locksmiths, Chubb Security of Sunbury-on-Thames.  The key, called
    Eloctro, has a tiny silicon chip which stores a unique number
    ranging from 10 to 70 000 billion.

    The key fits a special battery-powered lock which stores all the
    authorised numbers in a memory chip.  When a key is inserted, the
    lock generates an electromagnetic field, which is picked up by an
    antenna on the chip.  The antenna switches on the chip, allowing
    the lock to read the key's unique number.  If the number matches
    one in the lock's memory the key can turn.

    The numbers in the lock's memory can be stored individually, by
    inserting a controllor's key followed by the numbered key; or, a
    computer can load a list of authorised numbers.

    Although individually numbered swipe cards have been available for
    years storing the number on a chip is more secure because it is
    almost impossible to read or reprogramme the number without
    breaking the key.  It is not available for homes yet.

Several rather evident risks there.

___Pete   kaiser@heron.vbo.dec.com   +33 92.95.62.97 FAX +33 92.95.50.50


Safety in Telescript, Part Deux

"Luis Valente" <luis_valente@genmagic.genmagic.com>
31 Jan 1994 10:54:14 -0800
Following my posting to RISKS on January 17 entitled "Safety in
Telescript" a number of readers have strongly questioned some of the
statements I made in that posting. Two of those statements, in which I
used casual or imprecise language, were particularly criticized:

1- "Telescript is interpreted and, thus, is safer than compiled
languages." As pointed out by many readers, an interpreted language is
not intrinsically safer than a compiled language. It is the Telescript
language definition that provides that protection. Within the abstraction
created by Telescript, programs lack operations for directly manipulating
the physical resources of the "real" computer(s) on which they execute.

That doesn't mean that Telescript programs cannot interact with
applications (e.g., databases) outside the Telescript abstraction.
However, that interaction can only take place via Telescript objects that
act as proxies for the "external" applications. Each such proxy object
defines the features of the corresponding external application that are
to be made available to Telescript agents and places. It may also define
and enforce a security policy for controlling access to those features
(e.g., based on an agent's credentials and permit). Furthermore, the
administrative authority for a given Telescript engine is capable of
controlling (by means of mechanisms built into the language) who can and
cannot create these proxy objects.

2- "Authority names are cryptographically generated and cannot be
forged." Obviously, that statement is not true in an absolute sense since
the "unforgeability" of the authority name is directly related to the
cryptographic mechanism used to generate it. We currently use RSA-based
public key cryptography for generating authority names. Entitlement to
use a particular authority name can be linked to the secret key used to
generate it.

Aside from the criticism leveled against my poor choice of words in the
aforementioned statements, several readers complained about the lack of
more detailed information on the security technology used by Telescript,
namely, what cryptographic algorithms are used, key sizes, key
distribution and management issues, exportability issues, etc.

Let me start by saying that my posting was not meant as a treatise on
Telescript Technology but merely a brief description of some of the
features of Telescript that can be used effectively against misprogrammed
or ill-intentioned telescripts.

General Magic has already published a white paper entitled "Telescript
Technology: The Foundation of the Electronic Marketplace." This paper
provides a high-level description of Telescript and is intended for the
layman, not the techno-savvy reader. It can be requested directly from
General Magic by calling (415) 965-0400. In the coming months we will
publish additional information on many different aspects of Telescript
Technology (including security).

Let me further say that the point of my original posting was not that
Telescripted networks are intrinsically secure (i.e., the "it won't
happen here" syndrome). It was simply to let RISKS readers know that we
have put a lot of thought into the security aspects of Telescript. In
fact, when General Magic started developing Telescript, security was at
the top of our list of concerns. As a result, we have built into the
fabric of the language a number of features that, we believe, will enable
application developers to write safe Telescript programs and network
operators to run highly secure Telescripted networks.

Heretofore, the discussions on RISKS have only covered a few of the many
security issues faced by a dynamic, interpreted, communication-centric
language like Telescript. As more detailed information on Telescript
becomes widely available, I am certain it will generate heated debates on
this and other forums. I look forward to them!

-Luis Valente, General Magic, Inc.


Risks of email exacerbating typos

M. Hedlund <hedlund@netcom.com>
Tue, 8 Feb 1994 20:03:17 GMT
>From the New York Times, Tuesday, February 8, p. C5:

E-mail apparently made a bad situation worse for Bon Marche, a department
store in Washington, Oregon, Idaho, Montana, and Wyoming.  The store
misprinted a sale price for a Sony five-disk carousel CD player as $99, when
it was intended to be $179 (on sale from $199).  The NYT reports that nearly
5,000 people took advantage of the misprint, some placing paid orders once
available stock had been sold.

One salesman called attention to an unusual risk of email:

    The surge came in part because some employees at the Microsoft
    Corporation, based in nearby Redmond, had mentioned the deal in
    electronic-mail messages, he said.

Although the store could have run a correction ad or posted a disclaimer, they
did not; the price, according to the senior VP for marketing John Buller, "was
not totally irrational for this product."  I suppose the risk shouldn't keep
us up nights.

M. Hedlund


Patents Hearing as it relates to Software

Paul Robinson <PAUL@TDR.COM>
Tue, 8 Feb 1994 22:23:46 -0500 (EST)
Those of you on the West Coast be advised that there will be a hearing on the
issue of Patents as they relate to the issues of software development.  The
hearing is scheduled for February 10, in Room J of the San Jose Convention
Center, San Jose California, starting at 9:00 or so.

There will be a subsequent hearing on the East Coast a couple of days later,
near the Patent Office in Crystal City, Virginia.

A copy of the notice as published in the Federal Register (about 45K) was
posted to several lists on the Internet almost a month ago.  It is possible to
go to the hearing(s) to see them, but it is too late to sign up to speak, I
believe.  However, comments on the Federal Register notice may be E-Mailed to
Jeff Kushan <kushan@uspto.gov>.

Paul Robinson - Paul@TDR.COM


Network surveys et al.

Steve Holzworth <sch@unx.sas.com>
Wed, 9 Feb 1994 11:29:30 -0500 (EST)
Craig DeForest (zowie@daedalus.stanford.edu) describes how an automated
survey daemon managed to show him a list of other subscribers to a
political-speech service. I had a similar, but more serious incident occur
on my account with a commercial Internet access provider.

The access provider (approximately 1000 users), in the interests of security,
routinely runs one of the many password cracking programs against their
/etc/passwd file. One day, I received Email stating that my password was
weak (it was). The interesting thing about the Email is that it included
a list of all recipients of the same message; the To: field was a concatenated
string of all users with weak passwords...

I sent Email to the operator, advising that this might not be the best
strategy for dealing with the problem :-). He assured me that this was a
one-time slip, due to his having used a Email command that improperly
included the full distribution list... Sigh.

The site DOES use a shadow password file, so it's not as bad as it could be.

Steve Holzworth
sch@unx.sas.com                    "Do not attribute to poor spelling
SAS Institute   x6872               That which is actually poor typing..."
SAS/Macintosh Development Team                            - me
Cary, N.C.


Re: Don't Trust The Phone Company (Bodine, RISKS-15.46)

Lars Poulsen <lars@eskimo.CPH.CMC.COM>
Wed, 9 Feb 94 14:03:35 +0100
Tom Bodine reports the unsettling experience of being accused of making an
obscene phone call, after the husband of the recipient of the call (his wife's
best friend) used the "call return" feature at the end of the obscene call,
and then reached his number.  He speculates that his number was captured by
the friend's telephone switch as the result of a failed call from his wife
while the friend's line was busy with the obscene call.

While such a feature interaction is possible (is the number supposed to be
captured on a busy ? I know it is on a no-answer failure), there is another
way for this to occur: The perpetrator may have applied the call forwarding
feature on his own phone prior to making the call, and left it there for a bit
afterwards. In this situation, the number that was captured would not be the
Bodines', but that of the perpetrator. The effect would be the same, however,
except that if the call is a billable long distance call, the number would
show up on the next phone bill, and in the case of forwarding it would be the
perpetrator's number (since the last leg of the call is billed to the
forwarding phone).

I believe that there is no such interaction problem in the case of the
"calling number identification" feature, since the number is delivered in real
time and only when the call rings through. Thus, the call that would come in
DURING the problem call, would only be recorded if the recipient had the "call
waiting" feature, and in that case would not get busy, but ringback, and the
CNID (if subscribed) would be delivered between the rings (call waiting
tones)).

I am forwarding this note to the TELECOM DIGEST where someone from AT&T or
Bellcore will probably be able to look up whether the mechanism surmised by
Tom Bodine is also possible. I hope that this technical information will go
some way towards repairing relations between the families.


Re: "Misunderstanding" a CERT advisory

"D.R.NEWMAN" <FIG0008@v2.qub.ac.uk>
Wed, 9 Feb 94 18:55 GMT
Expect journalistic exaggeration. 2 people died in a cyclone on the
island of Mauritius in the 1970s. In the Kenyan papers this was 20 - in
the British papers 200. Now if CERT sued for libel and got damages, that
might get the journalists to check their facts!

Dr. David R. Newman, Queen's University, Information Management
Dept., BELFAST BT7 1NN, Northern Ireland. <d.r.newman@qub.ac.uk>


Re: Clipper Petition

Technology Strategy & Architecture <kaiser@heron.enet.dec.com>
Wed, 9 Feb 94 08:28:38 MET
Someone of my acquaintance (who doesn't care to be identified here) sent in a
response to CPSR's Clipper petition and received a full and explanatory
confirmation from CPSR at the address from which it was sent.  So if CPSR is
also culling out signatures from bogus addresses, those two measures together
are a good beginning.

___Pete   kaiser@heron.vbo.dec.com   +33 92.95.62.97 FAX +33 92.95.50.50


Re: Clipper Petition

"john (j.g.) mainwaring" <crm312a@bnr.ca>
Wed, 9 Feb 1994 11:11:00 +0000
In Risks issue 46, David Gursky mentions the possibility that some of the
responses to the CPSR petition will be of the "Vote early, vote often"
variety, and goes on to cite previous discussion of the risks of dial up
voting.

Petitions are not votes.  CPSR does not claim to be collecting votes on
Clipper and tallying the ayes, nays and throat clearings.  Petitions are an
unsupervised form of expression.  The older paper variety could be padded
pretty easily too.  Other risks associated with petitions (electronic or not)
include the possibility of bias in the question to manipulate response: "Even
though the President claims to have stopped beating his wife, it is the
opinion of responsible rabble rousers in this great country that..."  Anybody
who's been in politics even as long as our present youthful president knows
that petitions can be manipulated, and adds salt accordingly.

The theatrical value of collecting a petition about the electronic
superhighway in the rest stops of the present byways is obvious.  The strong
risk that the petition will include invalid responses needs to be weighed
against the risk of having an unnecessarily expensive and possibly
untrustworthy security system in future.  Or does anyone believe that Clipper
would make collecting petitions safe from democracy?


Re: Altered White House Documents (Roberts/Crawford, RISKS-15.46)

<firth@SEI.CMU.EDU>
Wed, 9 Feb 94 10:39:22 -0500
RISKS-15.46 reports on how an electronic document available from
whitehouse.gov was surreptitiously changed without any visible audit trail.

The relevant quote came to mind immediately:

    "He who controls the past controls the future."

I believe the answer is an independent party that will daily download all
documents from this site and systematically scan for similar attempts to
revise history.


Re: Altered White House Documents (Roberts/Crawford, RISKS-15.46)

Larry Nathanson <lan@panix.com>
8 Feb 1994 17:26:04 -0500
Perhaps a site on the net with a little bit of spare disk space would like to
mirror this site???  I know I'd find the 'diff's more informative than the
speeches themselves.


EFF Wants You (to add your voice to the crypto fight!)

Stanton McCandlish <mech@eff.org>
7 Feb 1994 17:34:17 -0600
The Electronic Frontier Foundation needs your help to ensure privacy rights!

                     * DISTRIBUTE WIDELY *

Monday, February 7th, 1994

From: Jerry Berman, Executive Director of EFF, jberman@eff.org

Dear Friends on the Electronic Frontier,

I'm writing a personal letter to you because the time has now come for
action. On Friday, February 4, 1994, the Administration announced that it
plans to proceed on every front to make the Clipper Chip encryption scheme
a national standard, and to discourage the development and sale of
alternative powerful encryption technologies. If the government succeeds
in this effort, the resulting blow to individual freedom and privacy could
be immeasurable.

As you know, over the last three years, we at EFF have worked to ensure
freedom and privacy on the Net. Now I'm writing to let you know about
something *you* can do to support freedom and privacy. *Please take a
moment to send e-mail to U.S. Rep. Maria Cantwell (cantwell@eff.org) to
show your support of H.R. 3627, her bill to liberalize export controls on
encryption software.* I believe this bill is critical to empowering
ordinary citizens to use strong encryption, as well as to ensuring that
the U.S. software industry remains competitive in world markets.

Here are some facts about the bill:

Rep. Cantwell introduced H.R. 3627 in the House of Representatives on November
22, 1993.  H.R. 3627 would amend the Export Control Act to move authority over
the export of nonmilitary software with encryption capabilities from the
Secretary of State (where the intelligence community traditionally has stalled
such exports) to the Secretary of Commerce. The bill would also invalidate the
current license requirements for nonmilitary software containing encryption
capabilities, unless there is substantial evidence that the software will be
diverted, modified or re-exported to a military or terroristic end-use.

If this bill is passed, it will greatly increase the availability of
secure software for ordinary citizens. Currently, software developers do
not include strong encryption capabilities in their products, because the
State Department refuses to license for export any encryption technology
that the NSA can't decipher. Developing two products, one with less secure
exportable encryption, would lead to costly duplication of effort, so even
software developed for sale in this country doesn't offer maximum
security. There is also a legitimate concern that software companies will
simply set up branches outside of this country to avoid the export
restrictions, costing American jobs.

The lack of widespread commercial encryption products means that it will
be very easy for the federal government to set its own standard--the
Clipper Chip standard. As you may know, the government's Clipper Chip
initiative is designed to set an encryption standard where the government
holds the keys to our private conversations. Together with the Digital
Telephony bill, which is aimed at making our telephone and computer
networks "wiretap-friendly," the Clipper Chip marks a dramatic new effort
on the part of the government to prevent us from being able to engage in
truly private conversations.

We've been fighting Clipper Chip and Digital Telephony in the policy arena
and will continue to do so. But there's another way to fight those
initiatives, and that's to make sure that powerful alternative encryption
technologies are in the hands of any citizen who wants to use them. The
government hopes that, by pushing the Clipper Chip in every way short of
explicitly banning alternative technologies, it can limit your choices for
secure communications.

Here's what you can do:

I urge you to write to Rep. Cantwell today at cantwell@eff.org. In the
Subject header of your message, type "I support HR 3627." In the body of
your message, express your reasons for supporting the bill. EFF will
deliver printouts of all letters to Rep. Cantwell. With a strong showing
of support from the Net community, Rep. Cantwell can tell her colleagues
on Capitol Hill that encryption is not only an industry concern, but also
a grassroots issue. *Again: remember to put "I support HR 3627" in your
Subject header.*

This is the first step in a larger campaign to counter the efforts of
those who would restrict our ability to speak freely and with privacy.
Please stay tuned--we'll continue to inform you of things you can do to
promote the removal of restrictions on encryption.

In the meantime, you can make your voice heard--it's as easy as e-mail.
Write to cantwell@eff.org today.

Sincerely,

Jerry Berman, Executive Director, EFF   jberman@eff.org

P.S. If you want additional information about the Cantwell bill, send
e-mail to cantwell-info@eff.org. To join EFF, write membership@eff.org.
For introductory info about EFF, send any message to info@eff.org.

The text of the Cantwell bill can be found on the Internet with the any of
the following URLs (Universal Resource Locaters):

ftp://ftp.eff.org/pub/Policy/Legislation/cantwell.bill
http://www.eff.org/ftp/EFF/Policy/Legislation/cantwell.bill
gopher://gopher.eff.org/00/EFF/legislation/cantwell.bill

It will be available on AOL (keyword EFF) and CIS (go EFFSIG) soon.

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

From: Stanton McCandlish <mech@eff.org>
Subject: Administration adopts coldwar mentality, pushes for Clipper

EFF Press Release            Feb 4 '94             * DISTRIBUTE WIDELY *

At two briefings, Feb. 4, 1994, the Clinton Administration and various
agencies gave statements before a Congressional committee, and later
representatives of civil liberties organizations, industry spokespersons
and privacy advocates.  The Electronic Frontier Foundation's position,
based on what we have seen and heard from the Administration today, is
that the White House is set on a course that pursues Cold War national
security and law enforcement interests to the detriment of individual
privacy and civil liberties.

The news is grim.  The Administration is:

 * not backing down on Clipper
 * not backing down on key escrow
 * not backing down on selection of escrow agents
 * already adamant on escrowed key access procedures
 * not willing to eliminate ITAR restrictions
 * hiding behind exaggerated threats of "drug dealers" and "terrorists"

The material released to the industry and advocacy version of the briefing
have been placed online at ftp.eff.org (long before their online availability
from government access sites, one might add).  See below for specific details.

No information regarding the Congressional committee version of the briefing
has been announced.  EFF Director Jerry Berman, who attended the private
sector meeting, reported the following:

"The White House and other officials briefed industry on its Clipper chip and
encryption review. While the review is not yet complete, they have reached
several policy conclusions.  First, Clipper will be proposed as a new Federal
Information Processing Standard (FIPS) next Wednesday. [Feb.  9] It will be
"voluntary" for government agencies and the private sector to use. They are
actively asking other vendors to jump in to make the market a Clipper market.
Export licensing processes will be speeded up but export restrictions will not
be lifted in the interests of national security. The reason was stated bluntly
at the briefing : to frustrate competition with clipper by other powerful
encryption schemes by making them difficult to market, and to "prevent" strong
encryption from leaving the country thus supposedly making the job of law
enforcement and intelligence more difficult.  Again in the interest of
national security. Of course, Clipper will be exportable but they would not
comment on how other governments will view this.  Treasury and NIST will be
the escrow agents and Justice asserted that there was no necessity for
legislation to implement the escrow procedures.

"I asked if there would be a report to explain the rationale for choosing
these results - we have no explanation of the Administration's thinking, or
any brief in support of the results. They replied that there would be no
report because they have been unable to write one, due to the complexity of
the issue.

"One Administration spokesperson said this was the Bosnia of
Telecommunications. I asked, if this was so, how, in the absence of some
policy explanation, could we know if our policy here will be as successful as
our policy in Bosnia?"

The announcements, authorization procedures for release of escrowed keys,
and q-and-a documents from the private sector briefing are online at EFF.

They are:

"Statement of the [White House] Press Secretary" [White House]
file://ftp.eff.org/pub/EFF/Policy/Crypto/wh_press_secy.statement

"Statement of the Vice President" [very short - WH]
file://ftp.eff.org/pub/EFF/Policy/Crypto/gore_crypto.statement

"Attorney General Makes Key Escrow Encryption Announcements" [Dept. of Just.]
file://ftp.eff.org/pub/EFF/Policy/Crypto/reno_key_escrow.statement

"Authorization Procedures for Release of Encryption Key Components in
Conjunction with Intercepts Pursuant to Title III/State Statutes/FISA"
[3 docs. in one file - DoJ]
file://ftp.eff.org/pub/EFF/Policy/Crypto/doj_escrow_intercept.rules

"Working Group on Data Security" [WH]
file://ftp.eff.org/pub/EFF/Policy/Crypto/interagency_workgroup.announce

"Statement of Dr. Martha Harris Dep. Asst. Secy. of State for Polit.-Mil.
Affairs: Encryption - Export Control Reform" [Dept. of State]
file://ftp.eff.org/pub/EFF/Policy/Crypto/harris_export.statement

"Questions and Answers about the Clinton Administration's Encryption
Policy" [WH]
file://ftp.eff.org/pub/EFF/Policy/Crypto/wh_crypto.q-a

These files are available via anonymous ftp, or via WWW at:
http://www.eff.org/ in the "EFF ftp site" menu off the front page.

Gopher access:
gopher://gopher.eff.org/
Look in "EFF Files"/"Papers and Testimony"/"Crypto"

All 7 of these documents will be posted widely on the net immediately
following this notice.

Contacts:

Digital Privacy: Jerry Berman, Exec. Director <jberman@eff.org>
                 Daniel J. Weitzner, Sr. Staff Counsel <djw@eff.org>
Archives: Stanton McCandlish, Online Activist <mech@eff.org>
General EFF Information: info@eff.org

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

From: Stanton McCandlish <mech@eff.org>
Subject: EFF Cantwell campaign update - a torrent of responses

EFF's "Letter to Cantwell" campaign, to collect and send letters to Rep.
Cantwell in support of her bill to ease export restrictions on cryptography,
collected more that *five hundred* responses the first day along, and at
5pmEST Tue. (2/8/94), was gaining more at a rate approaching 100 per *hour*.

To add your voice to this clear signal to Rep. Cantwell that her
legislation (bill HR 3627) is on the right track, send a message with a
subject line of "Subject: I support HR 3627" to cantwell@eff.org

Stanton McCandlish * mech@eff.org * Electronic Frontier Found. OnlineActivist

INFO@EFF.ORG FOR INFO: OPEN PLATFORM, ONLINE RIGHTS, VIRTUAL CULTURE, CRYPTO

Please report problems with the web pages to the maintainer

x
Top