Subject: RISKS DIGEST 10.83
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest  Tuesday 29 January 1991 Volume 10 : Issue 83

       FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

 Contents:
Risks of automatic flight (flying at low level) (Olivier M.J. Crepin-Leblond)
Broadcast local area networks are a'comin (Tom Lane)
Re: Risks in forensic use of dental and medical records (Jim Purtilo)
Re: Patriots (Clifford Johnson, Donald L. Wegeng)
Re: Random Voting IDs and Bogus Votes (Raymond Chen, Colin Plumb)
Call for Papers, 7th Computer Security Applications Conference (Daniel Faigin)
Call for papers, Theorem provers in circuit design (Victoria Stavridou)

The RISKS Forum is moderated.  Contributions should be relevant, sound, in
good taste, objective, coherent, concise, and nonrepetitious.  Diversity is
welcome.  CONTRIBUTIONS to [email protected], with relevant, substantive
"Subject:" line.  Others ignored!  REQUESTS to [email protected].
FTP VOL i ISSUE j: ftp CRVAX.sri.com<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR> (where i=1 to 10, j is always TWO digits. Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye" logs out.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

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

Date: Tue, 29 Jan 91 14:25 BST
From: "Olivier M.J. Crepin-Leblond" <[email protected]>
Subject: Risks of automatic flight (flying at low level)

Following is a translation of a short article published in a French newspaper
"Le Figaro", on 21st January 1991. It was part of a special supplement
describing the new electronic weapon systems the allies are currently using.

 Electronic navigation systems are now so advanced that the pilot of a fighter
airplane is not obliged to play an active role during the flying phase.  The
computer is in fact a better pilot in sorties involving penetration of enemy
territory by flying at very low altitude (under the sensitive radar zones). It
is not prone to tiredness, and much better at avoiding obstacles: it is
therefore possible to fly at supersonic speed ( < 1000 km/h) in a hilly region,
whilst constantly being at an altitude of 15 metres from the ground.  This is
very reliable, since the sensors of the airplane constantly provide data which
the navigation systems computer uses.
 Unfortunately, the actual pilots cannot stand this type of passive flight.
Not because by vanity, but because they tend to get sick: the U.S. Air Force
has found out during experimental missions that even the best and toughest of
pilots gets sea-sick after a few minutes when submitted to accelerations and
bearing changes that he did not generate himself.
 This is so serious that when some pilots arrived at the target site, they had
lost all faculties of analysis, and as a result the U.S. Air Force has decided
to abandon at least partially the concept of automated piloting for very low
altitude flights. "

Olivier M.J. Crepin-Leblond, Elec. Eng., Imperial College London, UK.

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

Date: Tue, 29 Jan 91 11:30:10 EST
From: [email protected]
Subject: Broadcast local area networks are a'comin

Today's New York Times states (on page two of the business section) that
Apple has filed with the FCC to reserve radio bandwidth for use in wireless
local area networks.  Instead of running LAN cable all around your building,
you put low-power transmitter/receivers in all your machines, and away you
go.  The assigned bandwidth would be used by all comers on a first come,
first served basis within each area, much as cordless phones or garage door
openers are now.  They estimate 150ft as the useful radius of communication;
data rates would be the same as wired LANs (10Mb/sec or so).

The risks should be pretty obvious to readers of this digest.  Somebody in
the next building could eavesdrop on your traffic, or actively connect into
your net, with NO special hardware.  I sure hope Apple is at least planning
to encrypt the packets---no mention of this, or of any security concerns, in
the article.  (But if they are going to support 10Mb/sec data rates, the
encryption would have to be fairly weak, methinks.)

If I ran a corporate network, I wouldn't touch this with a 10-foot pole.

                       tom lane

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

Date: Mon, 28 Jan 91 15:26:31 -0500
From: [email protected] (Jim Purtilo)
Subject: Re: Risks in forensic use of dental and medical records

I can offer first-hand experiences concerning use of technology in forensics.
Some colleagues and I have developed software systems to help manage forensic
information `in the field' following a mass casualty disaster.  Initially we
focused upon dental information, where the goals are to capture both antemortem
and postmortem records rapidly, then suggest possible matches between them.
Based upon suggestions from the software, an expert would take the time only to
perform an autopsy (in order to confirm the match) once enough confidence had
been built up by the software that the match was likely.  Previously, only
paper records were kept; matches were based upon having medical examiners pick
up a file folder of raw records, and then walk down a long row of human
remains, comparing each in turn until a possible match was found.  With our
software, both goals are attained:

1. Some amount of organization was brought to raw data that begins to gush
  forth after a tragedy (dentists employ many recording schemes, most of
  them conflicting, it seems).

2. The heuristic we developed for suggesting matches works.  Our first
  suggestion for a possible match has proven to be correct better than 95%
  of the time, based upon analysis of records that have been made available
  to us following previous air disasters.

So much for the advertising.  Now for the nitty gritty.  The only way we can
obtain this success is by *ignoring* much of the key information that an expert
would use to help make a positive identification!  Earlier versions of our
program attempted to consider detailed information about such things as root
canals, the quality of tooth enamel (hypoplasia, abrasions, mottled), and shape
of incisors.  The program was magnificently successful when used with quality
information.  However, our testing showed that there is almost no quality
information to be had in the first place.  Dentists (some!)  will charge for
work not done, or will mark the wrong tooth on paper records when in a hurry to
get to the next patient (off by one, or right index from wrong side of mouth).
They will mark down the wrong type of filling material.  Or they won't update a
patent's records if they find new work done there by someone else (say, the
patient was on the road, needed a quick filling by someone near at hand).  And
so on.  Never mind the problems that any program will have should you send out
for the records of "Jane and John Doe", only to find Jane answers the phone,
but John's secretary is missing...

Next, the transcription problem.  Lots of data, with diverse formats and
inconsistent attention to details, cannot be accurately transcribed by
assistants conscripted by airlines (or local ME office, or whatever).

With experiments, we were able to find a choice of parameters that is least
likely to be screwed up in the original antemortem form, is sufficient to get
us very close in suggested matches, and yet is simple enough that a spreadsheet
editor can let users enter all the material on one screen.  By giving up the
urge to use all the data and be *exact*, we were able to find a solution that
got very close.  In this case, this is sufficient to guide expert users, who
will then make very good use of their time (confirming matches, not investing
time looking for them).

In summary, Sherizen's observation is correct:  the key problem is obtaining
accurate information in the first place (i.e., we have rediscovered GIGO).
The key engineering problem, therefore, is anticipating common error modes
and adapting our technology accordingly.

Jim Purtilo, Computer Science Department, University of Maryland

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

Date:      Tue, 29 Jan 91 10:57:45 PST
From: "Clifford Johnson" <[email protected]>
Subject: Patriots

There was an accidental Patriot launch in Turkey of two Patriots against
aircraft returning from Iraq.  Four aircraft took evasive action, and all
esacped.  Although the system was in anti-ballistic (vs. anti-aircraft) mode,
this does show the Patriot may be useless against anything other than
predictably moving hunks of metal, and that automatic launch on warning is as
dangerous as we thought.

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

Date:   Tue, 29 Jan 1991 10:47:13 PST
From: [email protected] <[email protected]>
Subject: Re: Patriot Missile

Dave Parnas writes in RISKS 10.82:
> There was no SDI software technology to be applied to Patriot.

Today I spoke with someone who works in an engineering capacity with a US Army
guided missile group (I didn't ask if my source minded being quoted, so I won't
be more specific).  According to my source, the sensors that are currently
being used on Patriot missiles to track BMs were developed as part of the SDI
program (recall that the Patriot was originally an anti-aircraft system, and
thus used different sensors).  The first test of these new sensors on a Patriot
took place about six months ago at White Sands.  So while the Patriot itself is
not based on SDI technology, the sensors that it uses to track BMs are based on
SDI technology.
                                            Don Wegeng

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

Date: 29 Jan 91 18:48:59 GMT
From: Ed Wright <[email protected]>
Subject: Re: Patriots, and whats under them at intercept.

Some years back I was stationed with HHB 45th Arty (AD) a Nike Hercules unit.
45th ADA was located in Arlington Heights Il, a suburb of Chicago at the time.
The Herc had a high explosive warhead, but could also be fitted with one of
several nuclear warheads.  Contemplating the effects of a nuclear blast over
say Northfield ( a northern suburd of Chicago) and being willing to question
authority I posed to my superior the question "What good does it do to shoot
down a Russian bomber with a missle that will destroy the town under it ?"  and
the reply was "Well son .... what would you rather have: ## kilotons over
Evanston, or 10 to 50 megatons over the loop ?"  Now at the time it almost made
sense, 10 to 50 mt over the loop would sure negate the suburbs, and ## kt in
the burbs would only cause significant damage to the loop area. Please note the
key word is almost.  I have no doubt that the same mindset is in use today and
the question has got to be: "Well son, would you rather have big burning
fragments of Patriot and Scud over the burbs or a Scud downtown ?"  {Could that
be Scud or Scud Lite ? :-) } I sure as hell don't have the answer.  Ed Wright

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

Date: Mon, 28 Jan 91 11:34:09 PST
From: [email protected] (Raymond Chen)
Subject: Re: Random Voting IDs and Bogus Votes (Vote by Phone)

In <RISKS DIGEST 10.81> [email protected] proposed a partial precaution
against bogus-vote insertion, namely that some votes be tagged `negative',
meaning that the votes cast are really reversed.  I leave the security and
sociological consequences to more qualified folk.

I address the following claim:

>(even if I write down +1234567, I could have
>mentally remembered it to be a negative number.  Now I remember 1 bit
>information, not a long random number).

I wouldn't trust the public's ability to remember a single bit of information.
Indeed, even I have trouble remember whether the my front door is locked or
unlocked when the handle is in the vertical or horizontal position, and this is
a door I lock every day.

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

Date: Mon, 28 Jan 91 17:29:46 EST
From: [email protected] (Colin Plumb)
Subject: Voting by phone and buying votes

This is out of high school history, but fortunately that isn't too far in
the past for me:

The old technique for buying votes had a person watching on the way from the
voting booth to the ballot box.  You had to unfold your ballot and show them a
correctly marked ballot, then go and drop it in the box.  Then you got yor $5
(or whatever it was).  If not, you got a visit from some large guys.

Politics is almost the definitive dirty activity.  We need a very foolproof way
to prevent influence where we don't want it.  I'm not implying that anyone
today would engage in widespread abuse, but blatant vote-buying is not too long
in Canada's history, at least (I don't know about the U.S.), and it could
return in 25 years.

To be secure against bribery and intimidation of individual voters, it must not
be possible for A to prove to B that he did or did not vote for B.  (Well, if
*nobody* in A's district voted for B, then B has some idea, but...)

This is why I like the current method of constructing a human-readable ballot
and placing it in a box.  Recounts are possible, the voter can clearly see what
they're doing, and ensuring that there are initially no ballots in the box and
that each voter places at most one ballot in the box is relatively easy and can
be done by several witnesses.  It's not impossible to abuse, but it requires a
large conspiracy.

Will these voting by phone techniques prevent me from signing up a few hundred
drunks, having them vote from a telephone I supply, with me listening on an
extension, and giving them each a bottle of rum afterwards?  In a marginal
constituency, this could make a difference.

       -Colin

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

Date: Mon, 28 Jan 91 09:31:11 PST
From: [email protected]
Subject: Call for Papers -- 7th Computer Security Applications Conference

                        CALL FOR PAPERS AND PARTICIPATION

                        Seventh Annual Computer Security
                             Applications Conference
                               December 2-6, 1991
                               San Antonio, Texas

The Conference.  Operational requirements for civil, military, and commercial
systems increasingly stress the necessity for information to be readily
accessible.  The Computer Security Act of 1987 requires that all Federal
agencies take certain actions to improve the security and privacy provided by
federal computer systems. Accomplishing both operational and security
requirements requires the application of the maturing technology of integrated
information security to new and existing systems throughout their life cycle.
This conference will explore technology applications for both civil and
military systems; the hardware and software tools and techniques being
developed to satisfy system requirements; and specific examples of systems
applications and implementations.  Security policy issues and standards will
also be covered during this five day conference.

Papers and Tutorials.  Technical papers and tutorials that address the
application of integrated information security technologies in the civil,
defense, and commercial environments are solicited.  Original research,
analyses and approaches for defining the computer security issues and problems
identified in the Conference's interest areas; secure systems in use or
development; methodological approaches for analyzing the scope and nature of
integrated information security issues; and potential solutions are of
particular interest.  A prize of $500, plus expenses paid to attend the
conference, will be awarded for the best paper written by a student.  For
details contact Ravi Sandhu at the address below.

INSTRUCTIONS TO AUTHORS: Send five copies of your paper or panel proposal to
Ann Marmor-Squires, Program Chairman, at the address given below.  We provide
"blind" refereeing; put names and affiliations of authors on a separate cover
page only.  It is a condition of acceptance that manuscripts submitted have not
been previously published.  Papers that have been accepted for presentation at
other conferences should not be submitted.  Tutorial proposals should be sent
to Daniel Faigin at the address given below.

Papers and tutorial proposals must be received by May 17, 1991.  Authors will
be required to certify prior to June 19, 1991, that any and all necessary
clearances for publication have been obtained, that they will be represented at
the conference to deliver the paper, and that the paper has not been accepted
elsewhere.  Authors will be notified of acceptance by July 29, 1991.  Camera
ready copies are due not later than September 18, 1991.  Material should be
sent to:

          Ann Marmor-Squires           Daniel Faigin
          Technical Program Chair      Tutorial Program Chair
          TRW Systems Division         The Aerospace Corporation
          2751 Prosperity Ave.         P.O. Box 92957, MS M1/055
          Fairfax, VA  22031           Los Angeles, CA  90009-2957
          (703) 876-8161               (213) 336-8228
          [email protected]             [email protected]

Ravi Sandhu, Student Paper Award, George Mason Univ., ISSE Dept.,
Fairfax,  VA 22030-4444, (703) 764-4663    [email protected]

Areas of Interest Include: Advanced Architectures, C3I Systems, Trusted DBMSs
and Operating Systems, Public Law 100-235, Networks and Open Systems, Software
Safety, Policy and Management Issues, Risk/Threat Assessments, State-of-the-Art
Trusted Products, Electronic Document Interchange and Modeling Applicability,
Certification, Evaluation and Accreditation,            Current and Future
Trusted Systems Technology, Reviewers and Prospective Conference Committee
Members.

Anyone interested in participating as a reviewer of the submitted papers,
please contact Ann Marmor-Squires at the address given above.  Those interested
in becoming members of the conference committee should contact Dr. Ronald Gove
at the address below.

For more information or to receive future mailings, please contact the
following at:
          Dr. Ronald Gove                           Diana Akers
          Conference Chairman                       Publicity Chair
          Booz-Allen & Hamilton                     The MITRE Corporation
          4330 East-West Highway                    7525 Colshire Dr.
          Bethesda, MD  20814                       McLean, VA 22102
          (301) 951-2395                            (703) 883-5907
          [email protected]                  [email protected]

Victoria Ashby, Publication Chair, The MITRE Corporation, 7525 Colshire Dr.,
McLean, VA 22102        (703) 883-6368          [email protected]

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

Date: Fri, 25 Jan 91 15:00:32 GMT
From: [email protected]
Subject: Call for papers, Theorem provers in circuit design

                  C A L L   F O R  P A P E R S
                  INTERNATIONAL CONFERENCE ON
   T H E O R E M   P R O V E R S   I N   C I R C U I T   D E S I G N :
      T H E O R Y ,   P R A C T I C E   A N D   E X P E R I E N C E

            NIJMEGEN, THE NETHERLANDS, 22-24 JUNE, 1992

FOCUS AND OBJECTIVES

  Formal methods are increasingly seen as important in the design of digital
systems. The use of these techniques in practice is often regarded as being
strongly dependent on the support of appropriate mechanized theorem proving
tools.  The purpose of this conference is to provide a forum for discussing
the role of theorem provers in the design of digital systems. The objective
is to cover all relevant  aspects of work in the field, including original
research  as well as case studies and other practical experiments with new
or established tools.

  The primary focus will be on the ways in which formal methods are supported
by theorem proving tools, rather than on the theoretical foundations of
formalisms and design methods. The topics of interest include the philosophy
behind such tools, their design and development, their evolution, and their
evaluation through use. Of equal importance is the migration path of a theorem
proving tool and the associated technology into current digital engineering
practice.

 The intended audience includes workers in the field of hardware verification
as well as practising digital designers.


TUTORIALS

  It is intended that the conference will address, among other issues,
practical questions such as:

  Why use a theorem prover?
  Which theorem prover should I use?
  When should I use it?
  How should I use it?

  To enhance this aspect of the proceedings, the working sessions will be
complemented by tutorials on a variety of theorem proving tools and
associated topics. A Tutorials Chair has been established to ensure that a
wide range of systems are represented and to underline the importance that is
placed on the matter.


PROGRAMME AND PROCEEDINGS

  The conference programme will start with a day of tutorials and
demonstrations, followed by two days of presentations by contributing authors.
The programme will also include invited lectures by three prominent
researchers in the field of machine-assisted verification. The invited
speakers are:

  Mike Gordon, University of Cambridge.
  Warren Hunt, Computational Logic Inc.
  Dave Musser, Rensselaer Polytechnic Inst.


  A digest of papers will be made available to participants at the conference
and the proceedings will be published  after the conference.


ORGANIZATION

  The conference is organized by the Computer and Communications Systems Group
of the University of Nijmegen, the Netherlands. The conference organizers are:

     General Chair:
   Raymond Boute, University of Nijmegen.

     Programme Chair:
   Victoria Stavridou, University of London.

     Tutorials Chair:
   Tom Melham, University of Cambridge.

     Local Arrangements Chair:
   Huub van Thienen, University of Nijmegen.


PROGRAMME COMMITTEE

  The programme committee includes:

Albert Camilleri (HP Labs, UK)
Luc Claesen (IMEC, Belgium)
Ed Clarke (CMU, USA)
Mike Fourman (Edinburgh Univ., UK)
Joseph Goguen (Oxford Univ., UK)
Allen Goldberg (Kestrel Institute, USA)
Keith Hanna (Univ. of Kent, UK)
Warren Hunt (CLInc, USA)
Jeff Joyce (UBC, Canada)
Deepak Kapur (Albany SU, USA)
Dave Musser (RPI, USA)
Tobias Nipkow (Univ. of Cambridge, UK)
Paolo Prinetto (Politechnico di Torino, Italy)
Clive Pygott (RSRE, UK)
David Shepherd (Inmos, UK)
Joseph Sifakis (IMAG, France)


IMPORTANT DATES

  The important dates are as follows:

30 September 1991 :
      Final deadline for the submission of papers.
28 February 1992 :
      Date for notification of acceptance or rejection.
30 April 1992 :
      Final camera-ready copy due.
22-24 June 1992 :
      Conference at Nijmegen.

SUBMITTING A PAPER

  Four copies of a complete paper (in English) should be sent to the Programme
Chair at the address given below to arrive no later than  30 September 1991.
Papers must not exceed 6000 words in length, with full-page figures counted as
300 words.  Each paper should include a short abstract and a list of keywords
for subject classification.  All papers will be refereed and the final choice
will be made by the programme committee on the grounds of relevance,
significance, originality, correctness and clarity. Submitted papers must not
be published or under consideration for publication elsewhere in the same or
similar form. Authors of accepted papers will be sent LaTeX style files to
aid in the production of camera-ready copy.

PROPOSALS FOR TUTORIALS

  Proposals are solicited for tutorial presentations on relevant theorem
proving technology or tools. The intention is that a tutorial will provide
an overview of the basic ideas behind a theorem proving tool, rather than
detailed instruction in how to use it. Tutorials should include an assessment
of strengths and weaknesses of a tool and should concentrate on general issues
such as security, robustness, the degree of interaction required, the user
interface, and the mathematical skill required of the user.

  Proposals for tutorials should not exceed 1000 words in length and should
give a clear indication of the topic and structure of the presentation.
Also welcome are proposals for informal demonstrations of working systems.
Proposals for both tutorials and demonstrations should be sent to the
Tutorials Chair at the address given below to arrive no later than 30
September 1991.



ADDRESSES FOR CORRESPONDENCE

  Papers and all general correspondence should, in the first instance, be sent
to the Programme Chair at the following address:

Victoria Stavridou,
TPCD  Programme Chair,
Department of Computer Science,
RHBNC , University of London,
Egham Hill, Egham,
Surrey, TW20 0EX, United Kingdom.
Tel: (+44) 865 273808 (until 30/9/91)
Tel: (+44) 784 443429/3421 (after 30/9/91)
Fax: (+44) 865 273839/784 437520
Email: [email protected]

 Proposals for tutorials and demonstrations should be sent to the Tutorials
Chair:

Tom Melham,
TPCD  Tutorials Chair,
Computer Laboratory,
University of Cambridge,
New Museums Site, Pembroke Street,
Cambridge, CB2 3QG, United Kingdom.
Email: [email protected]

 All correspondence should include a return postal address and, if possible,
an electronic mail address.

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

End of RISKS-FORUM Digest 10.83
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.