Subject: RISKS DIGEST 10.83
REPLY-TO: risks@csl.sri.com

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 RISKS@CSL.SRI.COM, with relevant, substantive 
 "Subject:" line.  Others ignored!  REQUESTS to RISKS-Request@CSL.SRI.COM.
 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" <UMEEB37@vaxa.cc.imperial.ac.uk>
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: Tom.Lane@G.GP.CS.CMU.EDU
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: purtilo@cs.UMD.EDU (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" <GA.CJJ@Forsythe.Stanford.EDU>
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: wegeng@arisia.xerox.com <Donald_L._Wegeng.henr801c@xerox.com>
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 <edw@sequent.uucp>
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: raymond@math.berkeley.edu (Raymond Chen)
Subject: Re: Random Voting IDs and Bogus Votes (Vote by Phone)

In <RISKS DIGEST 10.81> li@helen.oracorp.com 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: ccplumb@rose.uwaterloo.ca (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: faigin@aerospace.aero.org
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        
           marmor@a.isi.edu    		faigin@aerospace.aero.org

Ravi Sandhu, Student Paper Award, George Mason Univ., ISSE Dept.,
Fairfax,  VA 22030-4444, (703) 764-4663    sandhu@gmuvax2.gmu.edu

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        
           Gove@dockmaster.ncsc.mil                  akers@mitre.org

Victoria Ashby, Publication Chair, The MITRE Corporation, 7525 Colshire Dr.,
McLean, VA 22102	(703) 883-6368		ashby@mitre.org

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

Date: Fri, 25 Jan 91 15:00:32 GMT 
From: Victoria.Stavridou@prg.oxford.ac.uk
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: victoria@cs.rhbnc.ac.uk
 
  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: tfm@cl.cam.ac.uk
 
  All correspondence should include a return postal address and, if possible, 
an electronic mail address.

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

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