The RISKS Digest
Volume 11 Issue 94

Tuesday, 18th June 1991

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

V-22 Osprey crashes on first flight
Martyn Thomas
Re: The Patriot system and the Dharan Scud: Time Warp
Rob Horn
AT&T & voice recognition
Ralph Moonen
More RISKS of stolen credit cards
Tsutomu Shimomura
Ethics, Drug Testing, and Hacking
Sanford Sherizen
Legion-of-Doom Goes Corporate
Craig Neidorf
Communications Privacy Statement
Marc Rotenberg
Dependable Computing: DCCA-3 call for papers
Carl Landwehr
Info on RISKS (comp.risks)

V-22 Osprey crashes on first flight

Martyn Thomas <mct@praxis.co.uk>
Tue, 18 Jun 91 12:43:18 BST
The fifth prototype Bell-Boeing V-22 Osprey tilt-rotor aircraft crashed one
minute into its maiden flight on June 1st, according to Flight International
(19-25 June, p 16). The pilots reported control problems, with the aircraft
feeling tail heavy and rolling from side to side.

The other four V-22s have 567 flight hours in 463 flights. The maiden flight
of number 5 was postponed last week after tools were found to be missing, but
only a drill-bit was found under the fuselage floor.

Flight-control software problems in another V-22 were traced to a faulty
switch.

Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.
Tel:    +44-225-444700.   Email:   mct@praxis.co.uk


Re: The Patriot system and the Dharan Scud: Time Warp (RISKS-11.92)

<HORN%HYDRA@sdi.polaroid.com>
Tue, 18 Jun 91 13:48 EST
A slight correction, the specification for Patriot was 14 hours of operation.
The 22 hour figure was the actual operational time for systems that did detect
the Scud but were out of range.  The origin of the 14 hour spec was the
original intended use of Patriot in defense of mobile forces where it was
expected that the systems would relocate several times per day, so the
assumption was not tacit.  It was a deliberate considered decision, balancing
procurement and operational costs against the operational needs.

For those who don't understand how a 0.36 second (or 1 ppm) error can cause
this problem, you have to examine how a machine tracks a target.  At initial
acquisition time you have a single location, but no speed or direction.  So you
put a ``box'' around the location and look again a very short time later.
Based upon the article, the timing error resulted in a mislocated box.  A
slower target (like an airplane) would still have been within the box.  A Mach
6 missile was outside the box.  So the computer did not associate the second
echo with the first echo.

This incident is a good illustration of the problem with the overemphasis of
formal proofs.  They are only as good as the specification being proved.  I
cannot find the reference, but I recall that more than half of the problems
found in current delivered systems can be traced to incorrect specification.

The issue of proper specification is important to all industries, not just
software.  It is time to start listening to the ideas that are being spread in
other industries.  A good starting point for a literature search is to read the
works of Deming, Juran, Taguchi, and Ishahawa.  Then look under keywords like
``Total Quality'' and ``Quality Function Deployment'' and expand from what you
find there.

Total Quality distinguishes three kinds of requirements:

- Expressed, those that the user actually states e.g. ``I want a hotel room
tomorrow night''.  These are the traditional totality of software requirements.

- Expected, those that are expected but not expressed e.g. that the hotel room
has a bed.  With Patriot, the expected but not expressed requirement was that
so long as the other hardware remained functional past its specified endurance
the software would also remain functional.

- Unexpected delights, those that are neither consciously wanted nor missed
when absent, like a spectacular view from the room window.

The goal of requirements setting is to understand and learn all three.  Many of
the techniques used exploit different formalisms to learn what people need.
They are based on the assumption that formalism is a tool to be used to clarify
communications.  Different or contradictory formalisms should be used so that
diverse personalities can all understand proposed requirements and make their
own comments and corrections.

Some of the diversities that need to be supported are:

  left-brain vs right-brain personalities

  actor vs object vs observer perspectives

  verbal (written word/ formula) vs aural (spoken/ lecture) vs
  visual (pictures) vs tactile (touch) oriented personalities.

You need to provide clear presentations that are oriented towards all of the
above.  One of the most difficult for computer systems requirements is the
tactile personalities.  Many people, especially those in the machinery field,
need something that they can touch and feel.  They may have been trained to
understand pictures that represent objects, but you can see their eyes light up
and their brain engage when you hand them a physical thing to understand.  The
traditional software documents are very poor communication tools with tactile
people.  This is a very real risk when more and more machinery involves
software components.  The people with the best understanding of machinery are
the ones for whom we provide the worst communications and understanding.

I suppose that this is vaguely related to the ongoing Formalism debate.  I do
know from both experience and the literature that men and women fall into all
of the above categories.

Rob Horn    horn%hydra@polaroid.com

   [Rob, Thanks for the correction on the 14 vs 22 hours; what you describe is
   exactly as it was stated in the AW&ST article.  I goofed.

   A comment to stave off objections from the formalists: bad specs
   are not an "illustration of the problem with the overemphasis of
   formal proofs."  They are an illustration of the problem with bad
   specs, which can effect system behavior — irrespective of whether
   formal methods are used!  PGN]


AT&T & voice recognition

<rmoonen@hvlpa.att.com>
Tue, 18 Jun 91 13:22 MDT
USA today had an article about a new AT&T product involving voice recognition.
This product would enable a shop-holder to call a number, read aloud his
merchant number, the credit card number, and the purchase price, and the
customer would be billed.

I mean, how much more RISK'ier can you get?
                                                       --Ralph Moonen


More RISKS of stolen credit cards

Tsutomu Shimomura <tsutomu@NO-SENSE.LANL.GOV>
Mon, 17 Jun 91 19:46:23 -0600
About 18 months ago, I had my wallet stolen.  Upon cancelling my credit cards
and receiving replacements, I was somewhat surprised to discover that one them
looked very familiar.  It had an account number which was one greater than the
one I'd just reported stolen (38XX-XXXXXX-XX11 instead of 38XX-XXXXXX-XX03;
the final digit is a checksum, uniquely determined by the preceding digits).
As it would be bad for a credit card thief to be able to trivially predict the
account numbers of replacement cards, I had written this off to coincidence.

This card was lost last week, and I just received the replacement.  The
account number follows in the obvious pattern: 38XX-XXXXXX-XX29.

It is still possible that this sequence is coincidental, but it would seem
most unlikely given the number of possible account numbers.

I hope the RISKS are recognized by the issuing bank (a large U.S. bank) before
they are recognized by the credit card thieves.
                                                           ---TS


Ethics, Drug Testing, and Hacking

Sanford Sherizen <0003965782@mcimail.com>
Tue, 18 Jun 91 14:46 GMT
I sometimes read the comics.  Only during off hours, hidden behind a computer
book, and in places where no adults can see me.  The Boston Globe on Thursday,
June 13, had a Dilbert comic strip that showed us how to balance some competing
risks.

MAN TALKING TO HIS DOG. "It's an ethical dilemma...I support my company's goal
of discouraging drug use, but the random drug testing policy is a violation of
my constitutional rights. I'll get fired if I refuse the test.  What is the
ethical thing to do?"

DOG TO MAN.  "Hack into their computer and change your boss's test results."

MAN USING THE COMPUTER AND TALKING TO DOG (AND HIMSELF).  "Sometimes the
straightest path is through the mud."

DOG RESPONDING TO MAN.  "Good, rationalize it with an obtuse metaphor."

Out of the mouths of comic strips ...
                                                  Sandy


Legion-of-Doom Goes Corporate

"Craig Neidorf" <C483307@UMCVMB.missouri.edu>
Tue, 18 Jun 91 11:32:59 CDT
AFTER YOU'VE BEAT 'EM — JOIN 'EM        (Time Magazine, 24 June 1991, p.13)

After infiltrating some of America's most sensitive computer banks, is there
any challenge left for a digital desperado?  Only to go legit, say three former
members of the notorious hacker group, the LEGION OF DOOM, who have quit the
outlaw game to start Comsec Data Security.  The Legionnaires claimed an 80%
success rate in penetrating computer networks, and now they want to teach
private industry to protect itself from the next generation of intruders.  "You
can't put a price tag on the information we know," says Scott Chasin, a Comsec
partner.  But they'll try.

(This article features a color photo of the three founding members:
 Erik Bloodaxe, Doc Holiday, and Malefactor.)


*Communications Privacy Statement*

<cdp!mrotenberg@labrea.Stanford.EDU>
Fri, 14 Jun 91 10:25:08 PDT
STATEMENT IN SUPPORT OF COMMUNICATIONS PRIVACY
Washington, DC                   June 10, 1991

    As representatives of leading computer and telecommunications
companies, as members of national privacy and civil liberties organizations, as
academics and researchers across the country, as computer users, as corporate
users of computer networks, and as individuals interested in the protection of
privacy and the promotion of liberty, we have joined together for the purpose
of recommending that the United States government undertake a new approach to
support communications privacy and to promote the availability of
privacy-enhancing technologies.  We believe that our effort will strengthen
economic competitiveness, encourage technological innovation, and ensure that
communications privacy will be carried forward into the next decade.

    In the past several months we have become aware that the federal
government has failed to take advantage of opportunities to promote
communications privacy.  In some areas, it has considered proposals that would
actually be a step backward.  The area of cryptography is a prime example.

    Cryptography is the process of translating a communication into a code
so that it can be understood only by the person who prepares the message and
the person who is intended to receive the message.  In the communications
world, it is the technological equivalent of the seal on an envelope.  In the
security world, it is like a lock on a door.  Cryptography also helps to ensure
the authenticity of messages and promotes new forms of business in electronic
environments.  Cryptography makes possible the secure exchange of information
through complex computer networks, and helps to prevent fraud and industrial
espionage.

    For many years, the United States has sought to restrict the use of
encryption technology, expressing concern that such restrictions were necessary
for national security purposes.  For the most part, computer systems were used
by large organizations and military contractors.  Computer policy was largely
determined by the Department of Defense.  Companies that tried to develop new
encryption products confronted export control licensing, funding restrictions,
and classification review.  Little attention was paid to the importance of
communications privacy for the general public.

    It is clear that our national needs are changing.  Computers are
ubiquitous.  We also rely on communication networks to exchange messages daily.
The national telephone system is in fact a large computer network.

    We have opportunities to reconsider and redirect our current policy on
cryptography.  Regrettably, our government has failed to move thus far in a
direction that would make the benefits of cryptography available to a wider
public.

    In late May, representatives of the State Department met in Europe with
the leaders of the Committee for Multilateral Export Controls ("COCOM").  At
the urging of the National Security Agency, our delegates blocked efforts to
relax restrictions on cryptography and telecommunications technology, despite
dramatic changes in Eastern Europe.  Instead of focusing on specific national
security needs, our delegates continued a blanket opposition to secure network
communication technologies.

    While the State Department opposed efforts to promote technology
overseas, the Department of Justice sought to restrict its use in the United
States. A proposal was put forward by the Justice Department that would require
telecommunications providers and manufacturers to redesign their services and
products with weakened security.  In effect, the proposal would have made
communications networks less well protected so that the government could obtain
access to all telephone communications.  A Senate Committee Task Force Report
on Privacy and Technology established by Senator Patrick Leahy noted that this
proposal could undermine communications privacy.

    The public opposition to S. 266 was far-reaching.  Many individuals
wrote to Senator Biden and expressed their concern that cryptographic equipment
and standards should not be designed to include a "trapdoor" to facilitate
government eavesdropping.  Designing in such trapdoors, they noted, is no more
appropriate than giving the government the combination to every safe and a
master key to every lock.

    We are pleased that the provision in S. 266 regarding government
surveillance was withdrawn.  We look forward to Senator Leahy's hearing on
cryptography and communications privacy later this year.  At the same time, we
are aware that proposals like S. 266 may reemerge and that we will need to
continue to oppose such efforts.  We also hope that the export control issue
will be revisited and the State Department will take advantage of the recent
changes in East-West relations and relax the restrictions on cryptography and
network communications technology.

    We believe that the government should promote communications privacy.
We therefore recommend that the following steps be taken.

    First, proposals regarding cryptography should be moved beyond the
domain of the intelligence and national security community.  Today, we are
growing increasingly dependent on computer communications.  Policies regarding
the appropriate use of cryptography should be subject to public review and
public debate.

    Second, any proposal to facilitate government eavesdropping should be
critically reviewed.  Asking manufacturers and service providers to make their
services less secure will ultimately undermine efforts to strengthen
communications privacy across the country.  While these proposals may be based
on sound concerns, there are less invasive ways to pursue legitimate government
goals.

    Third, government agencies with appropriate expertise should work free
of NSA influence to promote the availability of cryptography so as to ensure
communications privacy for the general public.  The National Academy of Science
has recently completed two important studies on export controls and computer
security.  The Academy should now undertake a study specifically on the use of
cryptography and communications privacy, and should also evaluate current
obstacles to the widespread adoption of cryptographic protection.

    Fourth, the export control restrictions for computer network technology
and cryptography should be substantially relaxed.  The cost of export control
restrictions are enormous.  Moreover, foreign companies are often able to
obtain these products from other sources. And one result of export restrictions
is that US manufacturers are less likely to develop privacy-protecting products
for the domestic market.

    As our country becomes increasingly dependent on computer
communications for all forms of business and personal communication, the need
to ensure the privacy and security of these messages that travel along the
networks grows.  Cryptography is the most important technological safeguard for
ensuring privacy and security.  We believe that the general public should be
able to make use of this technology free of government restrictions.

    There is a great opportunity today for the United States to play a
leadership role in promoting communications privacy.  We hope to begin this
process by this call for a reevaluation of our national interest in
cryptography and privacy.

Mitchell Kapor, Electronic Frontier Foundation
Marc Rotenberg, CPSR
John Gilmore, EFF
D. James Bidzos, RSA
Phil Karn, BellCore
Ron Rivest, MIT
Jerry Berman, ACLU
Whitfield Diffie, Northern Telecom
David Peyton, ADAPSO
Ronald Plesser, Information Industry Association
Dorothy Denning, Georgetown University
David Kahn, author *The Codebreakers*
Ray Ozzie, IRIS Associates
Evan D. Hendricks, US Privacy Council
Priscella M. Regan, George Mason University
Lance J. Hoffman, George Washington University
David Bellin, Pratt University

(affiliations are for identification purposes only)


Dependable Computing: DCCA-3 call for papers

Carl Landwehr <landwehr@itd.nrl.navy.mil>
Tue, 18 Jun 91 13:20:11 -0400
                        DCCA-3 Call for Papers
                    3rd IFIP Working Conference on
              Dependable Computing for Critical Applications
                       Can we rely on computers?

          Splendid Hotel La Torre, Mondello (Palermo), Sicily, Italy
                        14-16 September 1992
  Organized by
    IFIP Working Group 10.4 on Dependable Computing and Fault Tolerance
  In cooperation with
    IFIP Technical Committee 11 on Security and Protection in Information
             Processing Systems
    IEEE Computer Society Technical Committee on Fault-Tolerant Computing
    EWICS Technical Committee 7 on Systems Reliability, Safety and Security
    University of Pisa
    Istituto di Elaborazione dell'Informazione del CNR, Pisa
    Associazione Italiana per l'Informatica ed il Calcolo Automatico

  General Chair
    L. Simoncini
    University of Pisa, Italy
  Program co-Chairs
    C.E. Landwehr
    Naval Research Laboratory, USA
    B. Randell
    University of Newcastle upon Tyne, UK
  Local Arrangements Chair
    E. Ricciardi, IEI-CNR, Italy
  Program Committee
    J.A. Abraham, U of Texas, USA          B. Littlewood, City U, UK
    P. Bishop, National Power, UK          T. Lunt, SRI Int'l, USA
    A. Costes, LAAS-CNRS, France           J. Meyer, U of Michigan, USA
    D. Craigen, ORA Corp., Canada          M. Morganti, Italtel, Italy
    K. Dittrich, U of Zurich, Switzerland  S. Natkin, CNAM, France
    H. Ihara, Hitachi, Japan               J-J. Quisquater, Philips, Belgium
    R.K. Iyer, U of Illinois, USA          R.D. Schlichting, U of Arizona, USA
    J.P. Kelly, U of California, USA       F.B. Schneider, Cornell U, USA
    R. Kemmerer, U of California, USA      D. Siewiorek, Carnegie-Mellon U, USA
    H. Kopetz, Technische U Wien, Austria  L. Strigini, IEI-CNR, Italy
    J.H. Lala, CS Draper Lab, USA          I. Sutherland, ORA Corp, USA
    K. Levitt, U of California, USA        W.M. Turski, Warsaw U, Poland
  Ex Officio
    J-C. Laprie, LAAS-CNRS, France
    IFIP WG 10.4 Chair

  DCCA-3 is held in conjunction with the 12th IFIP World Congress (Madrid,
  Spain, 7-11 September  1992)

Increasingly, individuals and organizations are becoming critically dependent
on sophisticated computing systems. In differing circumstances, this dependency
might for example center on the continuity of service received from the
computing system, the overall performance level achieved, the real-time
response rate provided, the extent to which catastrophic failures are avoided,
or confidentiality violations prevented. The notion of dependability, defined
as the trustworthiness of computer service such that reliance can justifiably
be placed on this service, enables these various concerns to be subsumed within
a single conceptual framework with reliability, availability, safety and
security, for example, being treated as particular attributes of dependability.
This, the third IFIP Working Conference on the topic of Dependable Computing
for Critical Applications, aims to continue the very successful tradition
created by its predecessors (1989: Santa Barbara, California and 1991: Tucson,
Arizona). It will thus provide a venue for the presentation and detailed
discussion of research and advanced development relating to theory, techniques
and tools for specifying, designing, implementing, assessing, validating,
operating and maintaining critical computing systems. Of particular, but not
exclusive, interest will again be presentations which address combinations of
dependability attributes, e.g. safety and security, through studies of either a
theoretical or an applied nature.

Submitting a Paper: Six copies (in English) of original work should be
submitted by 31 January 1992, to the Program co-Chair:

    Dr. Carl E. Landwehr
    Code 5540
    Naval Research Laboratory   Tel:    +(1) 202 767 3381
    Washington, DC 20375-5000   Fax:    +(1) 202 404 7942
    USA                         E-mail: landwehr@itd.nr.navy.mil

Papers should be limited to 6000 words, full page figures being counted as 300
words. Each paper should include a short abstract and a list of keywords
indicating subject classification. Papers will be refereed and the final choice
will be made by the Program Committee. Notification of acceptance will be sent
by 25 May 1992, and camera-ready copy will be due on 15 July 1992. A digest of
papers will be available at the Conference, and hardbound proceedings will be
published after the Conference as a volume of the Springer-Verlag series on
Dependable Computing and Fault-Tolerant Systems.

Important Dates:
    Submission deadline: 31 January 1992
    Acceptance notification: 25 May 1992
    Camera-ready copy due: 15 July 1992

Please report problems with the web pages to the maintainer

x
Top