The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 4 Issue 24

Friday, 5 December 1986

Contents

o Criminal Encryption & Long Term effects
Baxter
o Criminals and encryption
Phil Karn
o Re: ATC Near-Collisions
Rony Shapiro
o High Availability Systems
PGN
o Plug-compatible modules
PGN
o "Satellite interference"
Lauren Weinstein
o Re: Privacy in the office
Brint Cooper
o ACARD Report
Samuel B. Bassett
o Info on RISKS (comp.risks)

Criminal Encryption & Long Term effects

<baxter@ICSD.UCI.EDU>
Thu, 04 Dec 86 17:54:14 -0800
In a previous RISKS article, mention was made of a prostitution ring that
used computers to keep track of the customer base.  It was only moderately
surprising that "criminal elements" would finally arrive at a use for data
processing technology (as opposed to victimizing it...).  Having built file
systems which automatically decrypt records when accessed (for password
storage, etc.), I have long been surprised that the use of encryption as a
technique for storing such transactions has not received widespread use, or
that at least a spectacular instance has not been uncovered.  For a bookie,
surely the convenience of pulling the plug on a computer during a police
raid and taking the 5th when asked for an encryption key must outweigh the
difficulty of handling and destroying flimsy tissues (no, I'm not sure what
technology bookies actually use).  The first conclusion is that computing
(and technology supporting privacy) may make a life of crime more convenient
and safer, raising the spectre of a permanently entrenched criminal
computing element.

A more chilling thought is perhaps the long term consequence of police
reaction to this: acquisition of privacy-breaking technology, and use of
such technology to detect criminal transactions before arrests occur.


Criminals and encryption

Phil Karn <karn@ka9q.ampr.net>
Fri, 5 Dec 86 03:17:51 EST
I am interested in documented criminal cases where defendants have encrypted
their communications or incriminating computer files and refused to divulge
the keys under their Fifth Amendment rights.  I am particularly interested
in the response of the legal system in such cases and the effect, if any,
encryption technology might have had on the outcome.  I can think of many
possible scenarios, such as:

1. The police either trick the defendent into revealing the key, or by
exploiting his carelessness (by finding it written down or easily guessed,
etc) recover the information which is then used in the prosecution.

2. When more than one person knows the key, one is given immunity and
compelled to divulge it to produce evidence against the other(s).

3. The police perform a successful cryptanalysis.

4. The police and prosecution are unable to recover the encrypted
information, but obtain a conviction anyway in the traditional way (through
witnesses, physical evidence, etc).

5. Without the encrypted information, the case is dropped due to lack of
evidence.

Much of the evidence in certain types of criminal cases consists of paper
records and intercepted telephone conversations obtained through warrants.
(Political corruption, drug rings and organized crime come to mind). I am
interested in the issue of how the widespread availability of computers and
encryption devices will affect the criminal justice system.  Clearly, it
will be impossible to keep this technology out of the hands of criminals (at
least in the US).  Will prosecutors find other, equally successful ways to
get convictions? Or will there be mounting pressure to erode Constitutional
due-process guarantees and the right against self-incrimination?  Even
worse, will there be misguided and futile attempts (along the lines of the
Electronic Communications Privacy Act) to control the availability of
computers within the United States in the name of "law and order" or
"national security"?

Phil


Re: ATC Near-Collisions

Rony Shapiro <ronys%wisdom.bitnet@jade.berkeley.edu>
Thu, 4 Dec 86 11:13:19 -0200
 I would like to comment on the article from Chicago (UPI) Dec 2 1986.

 The fact that the transponder on the light aircraft was defective may be
misleading. Air-traffic controllers are trained (at least here) NEVER to
rely on tranponder altitude reports when assigning altitudes to other
aircraft. In other words, the controller appeared to have erred in trusting
the transponder when giving the jet clearance to land.

 Transponders are not perfect, & their transmissions may get garbled,
especially in a crowded airspace, such as Chicago. However, as long as they
are regarded as such, they are a useful aid in air traffic controlling.

 Trusting transponders too much is a great temptation under heavy workloads
(easier than asking the pilot of the aircraft in question his altitude - the
only sure method), but the blame is with the ATC, & not with the transponder.

                Rony Shapiro. <ronys@wisdom>


High Availability Systems

Peter G. Neumann <Neumann@CSL.SRI.COM>
Thu 4 Dec 86 09:30:22-PST
There is an ad in the 4 Dec 86's SF Chron for "California's most convenient
ATMs".  The banner across a depicted terminal screen says "NOW 24 HOURS A DAY"
(implying that until recently it wasn't?).  The text of the ad says
"VERSATELLER ATMs are there ... when you need them ... With 24-hour service
all day and all night.*" (as opposed to 24-hour service just during the
day?)  The footnote in VERY fine print says "* Available at most locations
and subject to routine system maintenance 2 a.m. to 6 a.m. Sumday." 

        [There was a time when ATMs would run stand-alone when the central
         computer was down, but there were some cases of people grossly 
         exceeding limits intentionally during such times.  Is this no
         longer the case?  The Airline reservation systems also have the
         maintenance problem of having to shut down, but that is presumably
         because of large numbers of schedule changes that for some peculiar
         reason cannot be queued up dynamically and cut over at a particular
         time.  There are lots of interesting risks associated with upgrading
         and/or maintaining more time-critical systems that cannot afford to
         be down at all...  PGN]


Plug-compatible modules

Peter G. Neumann <Neumann@CSL.SRI.COM>
Thu 4 Dec 86 09:36:38-PST
The 4 Dec 86 SF Chron has an AP story on a 4-year old girl who was
electrocuted when a nurse accidentally plugged her heart-monitoring line
into an electrical circuit.  (Children's Hospital, Seattle WA)  Using a
standard male electrical plug on such a line seems incredible.  I mention
it here as a generalized example of the lack of strong typing (type safety).
Compatibility among different types is a common and serious problem in computer
programming languages and system calls, but this case is somehow amazing...


"Satellite interference" (CNN Headline News)

Lauren Weinstein <vortex!lauren@rand-unix.ARPA>
Wed, 3-Dec-86 12:33:42 PST
While misaimings and such are fairly common, they rarely result in total
capture of a satellite transponder, since it takes considerable power
to completely override the main signal.  In the case of the described
problem with CNN Headline News, the explanation is almost certainly
very simple and has nothing whatever to do with interfering signals.

Both CNN services (as are a variety of other satellite services) are scrambled 
with the VideoCipher II system (designed by MA/COM, now owned by General
Instruments).  The system uses DES technology and has the capability of an
in-the-clear "barker" audio channel that promotes the service and (in the case
of CNN) the sale of decoders as well.  The VC II technology is very sensitive 
to signal levels and quality--if the level drops off or glitches momentarily
the unit will fall back into its "deaddressed" mode and send the encrypted
video and the audible barker to the output (in most cases a cable system).
It can take anywhere from a second or two to many minutes (sometimes hours
under poor conditions) for the VC II to resync and restore normal output.

The case described almost certainly was a VC II dropout at the local
cable company that resulted in the encrypted picture and clear barker
being sent to the cable system subscribers.

By the way, the proposal the FCC has made about ID's in the vertical
interval will not sit well with many programmers--the vertical interval
is sometimes used for other purposes (teletext, audio services, etc.)
and those programmers can be expected to vigorously object to "wasting"
their interval on a visible I.D.  Of course, if only "occasional"
uplinkers (such as remote news crews) were required to do this, it would
not be such a problem since such crews virtually never are sending
any special vertical interval information.

--Lauren--


Re: Privacy in the office

Brint Cooper <abc@BRL.ARPA>
Wed, 3 Dec 86 23:13:16 EST
    All offices are not equivalent.  In components of the DoD, as we
are made painfully aware, "Use of official telephones implies consent to
monitoring."  How "they" monitor, whether computers are used, and how the
monitored content is validated, are anyone's guess.

Brint


ACARD Report

Samuel B. Bassett <well!samlb@lll-crg.ARPA>
Wed, 3 Dec 86 23:35:11 pst
     In regard to the ACARD report, it strikes me that what the British 
commission is trying to do is to force businesses and organizations to 
accept the idea of product liability in an increasingly critical area.  The 
British system allows the sort of "persuasion from on high" that we in the 
U.S. would never put up with.  (Can you imagine how much money would be 
available to a PAC to _defeat_ the first Congresscritter to introduce such 
a bill here?)

     It may be that this is a political "stalking horse" -- an early 
attempt to put the idea in the public domain, let it get argued over for a 
few years, and avoid a direct political battle in the near future.  The 
wording has that peculiar British Civil Servant flavor to it, which 
indicates to me that it is mostly a thoeretical exercise at the moment.

     In any event, serious programmers and software engineers should 
welcome the news of the report -- it will strengthen their hands when 
talking to management about realistic time scales for software projects.  
The literature has been full of breast-beating about how good software 
would be if management didn't persist in rushing it out the door without 
proper testing?  Now they have a good arguement to hit 'em with.

     Then too, in the last analysis, even if the report were enacted into 
law, it is doubtful if many (or any) programmers would go to jail -- but it 
would be almost certain that more than a few companies would lose a _lot_ 
of money.  Managers pay attention to such things . . .

Sam'l Bassett, Self-Employed Writer
34 Oakland Ave., San Anselmo  CA  94960;
DDD:         (415) 454-7282;     /  dual\
UUCP:        {...known world...}! lll-crg!well!samlb;
Compuserve:  71735,1776;         \hplabs/

Please report problems with the web pages to the maintainer

Top