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 6 Issue 30

Tuesday, 23 February 1988

Contents

o The risks of pressing the wrong key -- a taxing situation
Gligor Tashkovich
o Taxing of information
Steven Koinm
o Using viruses for copy protection
Doug McIlroy
o What's in a Name, III
Vint Cerf
John Pershing
o Re: Mistaken Identity
Amos Shapir
o Details of bank's costly computer foul-up
Rodney Hoffman
o Voice-print security (and Rory Bremner)
J M Hicks
o Auto-mated Citations
Mark Brader
o Re: Shuttle Security
Henry Spencer
o Info on RISKS (comp.risks)

The risks of pressing the wrong key -- a taxing situation

Gligor Tashkovich <gligor%lerouf.DEC@decwrl.dec.com>
21 Feb 88 13:01
Coopers & Lybrand did my rough French taxes on Friday (courtesy of Digital) by
computer.  When the agent went to pull a screen of information that he had
entered on me, he pressed the wrong key and up came personal tax information
that was for another employee of Digital in my subsidiary.  All the important
confidential information was there including salary, real estate owned, etc.

The risk here is that information that you give to a tax person on a 
confidential basis might not be that confidential after all ...


Taxing of information

Steven Koinm <goog@a.cs.okstate.edu>
17 Feb 88 07:48:28 GMT
I recently came across an interesting idea presented by a hacker while doing
research for a paper.  The hacker said that he could not consider
information property because it cannot be taxed.

But, what if it could.  How would you put a property tax on information?  How
can you say what the value of that information is?  It may be invaluable to 
you but it's still just a bunch of bits unless it is used?  Maybe if they 
were to keep track of each time you used a piece of information and then based
the amount of tax on that?

Would this make people stop collecting HUGE amounts of information that they
keep around just for the sake of "I'll need that someday" or "Why bother 
erasing it, it may still be valid."  

I just thought that this was an interesting thought...

GOOG ?? (a.k.a. Steve Koinm)                     
Computing and Information Sciences       Internet:  goog@a.cs.okstate.edu
Oklahoma State University                UUCP: {cbosgd, ihnp4,
Stillwater, OK  74075                           rutgers}!okstate!garnett 


Using viruses for copy protection

<doug@research.att.com>
Mon, 22 Feb 88 08:17:49 EST
I've not heard actual instances of latent viruses being used for copy
protection, although one of your correspondents asserted that had been done.
Anybody contemplating such a gimmick, however, had better think twice.  If you
booby trap your house and injure a burglar, or if you string a wire across a
hikers-only trail and decapitate an illegal biker, you are criminally liable.

Doug McIlroy


Jr., Sr., III (RISKS-6.29)

<CERF@A.ISI.EDU>
21 Feb 1988 00:20-EST
RE: Mr. William E. Brown III, it's a good thing his name isn't
William W. Brown III or his card would read W W III !!

RE: systems that don't deal with trailers on names like Jr., Sr. or
III, MCI Mail specifically parses for these.
                                                    Vint

                         [Because Vint does not have one of these trailers, 
                         he cannot be accused of being Self-Cerfing.  PGN]


John Pershing <PERSHNG@ibm.com>
23 Feb 88 11:22:11 EST
The letters that I find most amusing are the ones that I get every couple
of months that start out long the lines of:

    A personal message for JOHN A PERSHING JR:

    Dear Mr. Jr:
    ...

Also, back when I was in college, our fraternity was listed in the phone
book as "Kappa Sigma Frat".  One day, we got a bulk mailing declaring
"Good News for the Frat Family" addressed to Mr. K.S. Frat, claiming that
an arduous genealogical search had turned up the Frat Family coat of
arms, which they wanted to send to us (for a price, of course).

John A. Pershing Jr., IBM, Yorktown Heights

[Live off the Frat of the Land and operate under a strict Coat of Alms.  PGN]


Re: Mistaken Identity (RISKS DIGEST 6.29)

Amos Shapir NSTA <amos@nsc.NSC.COM>
Mon, 22 Feb 88 09:27:57 PST
The Israeli state collection agency issued a warrant for the arrest of a
debtor; since they had only his name (a rather common one) and the town he
lived in, a clerk completed the missing information - full address, ID number
and father's name - from the first entry for a person of the same name he found
in the citizen's registry.  That person had a very hard time (including an
overnight arrest) explaining to the authorities that it's not him ("but it is
*your* ID on the arrest form, isn't it?!").
                                                      Amos Shapir

National Semiconductor 7C/266  1135 Kern st. Sunnyvale (408) 721-8161
amos@nsc.com till March 1, 88; Then back to amos%taux01@nsc.com 

     [This one is computer-related in the sense that input data should
     acquire an appropriate measure of trustworthiness and then be
     handled accordingly.  That measure should stay with the data, as
     is the case with a security label.  PGN]


Details of bank's costly computer foul-up

Rodney Hoffman <Hoffman.es@Xerox.COM>
7 Feb 88 18:36:54 PST (Sunday)
In RISKS-5.16 (25 July 1987) and again in RISKS-6.16 (27 January 1988), I
related news accounts of Bank of America's failed attempt at an ambitious new
trust accounting and reporting system.

The Los Angeles Times for Sunday, February 7, 1988, carried a lengthy front-page
review of the entire debacle, "B OF A'S PLANS FOR COMPUTER DON'T ADD UP" by
Douglas Frantz.  The article includes lots of background history and economics.
Here are a few edited excerpts giving more details than the previous accounts:

  Last month, Bank of America acknowledged that it was abandoning the $20 
  million computer system after wasting another $60 million trying to make 
  it work.  The bank will no longer handle processing for its trust division, 
  and the biggest accounts were given to a Boston bank.  Top executives 
  have lost their jobs already and an undisclosed number of layoffs are in
  the works.

  ...The total abandonment of a computer system after five years of develop-
  ment and nearly a year of false starts raises questions about the bank's
  ability to overcome its technological inadequacy in an era when money is
  often nothing more than a blip on a computer screen....   

  In 1981, the bank had fallen far behind in the computer race.  Then-new
  chairman Armacost launched a $4-billion spending program to push B of A 
  back to the technological forefront.  The phrase he liked was "leap-
  frogging into the 1990s," and one area that he chose to emphasize was 
  the trust deparment.... 

  The bank was mired in a 1960s-vintage accounting and reporting system.  
  An effort to update the system ended in a $6-million failure in 1981 
  after the company's computer engineers worked for more than a year with-
  out developing a usable system.....  

  In the fall of 1982, bank officers met Steven M. Katz, a pioneer in creat-
  ing software for bank trust departments.... In 1980, he had left SEI Corp. 
  in a dispute and founded rival Premier Systems.

  Katz insisted on using Prime instead of B of A's IBM computers.  He boasted 
  that he could put together a system by 1983.  Within six months, a B of A - 
  led consortium of banks agreed to advance Premier money to develop a new, 
  cutting-edge system for trust reporting and accounting.  Nearly a year was 
  spent on additional research....  The go-ahead to fund to project came in 
  March, 1984.  While it was not a deadline, the goal was to have the new  
  system in operation by Dec. 31, 1984.

  What followed was a textbook structure for designing a computer system.  A
  committee was formed of representatives from each B of A department that
  would use the system and they met monthly to discuss their requirements.  
  DP staff gathered for a week each month to review progress and discuss 
  their needs with the Premier designers.  Some of the DP experts found Katz
  difficult to deal with occasionally, especially when they offered views on
  technical aspects of the project.  "Don't give us the solutions.  Just tell
  us the problems," Katz often said.

  When the ambitious Dec. 31, 1984, goal was passed without a system, no one
  was concerned.  There was progress, and those involved were excited about 
  the unfolding system and undaunted by the size of the task.  B of A devoted
  20 man-years to testing the software system and its 3.5 million lines of
  code; 13,000 hours of training, including rigorous testing, were provided
  to the staff that would run the system....

  In spring 1986, the system was about ready.  Some smaller parts were already
  working smoothly.  Test runs had not been perfect, but the technicians
  thought most bugs could be worked out soon.  A demonstration run had been
  successful....

  Many employees were operating both systems, working double shifts and
  weekends.  Late in 1986, an anonymous letter warned against a "rush to
  convert" to the new system and told the manager, not a computer expert, 
  that people had "pulled the wool" over his eyes.  The executive assured 
  the staff that there would be no conversion before it was time.  By then,
  lines of authority had also changed, making cooperation difficult.

  By early 1987, tests had been running with only a few bugs.  "There were
  still bugs, but the users felt they could run with it and work out the
  bugs as we went along," one former executive said.  A conversion date was
  set:  March 2, 1987.  

  Just then, half the DP staff was pulled off the assignment.  The conversion
  lasted one week.  On March 7, the first of the 24 disk drive units on the 
  Prime computers blew up, causing the loss of a portion of the database.  It
  was past midnight each night before workers retrieving data from a backup
  unit left the offices.  Over the next month, at least 14 more of the disk 
  drives blew up.  None had malfunctioned in the previous months of test.  

  It turned out that the units were part of a faulty batch manufactured by
  Control Data Corp.  But by the time the cause was discovered, delays had
  mounted and other difficulties had arisen.  Taken individually, none would
  have caused the ensuing disaster.  Together, they doomed the system.  

  At the same time, the bank decided to move the main staff 30 miles away.  
  Key people quit and morale sank.  Another section of staff was told they
  would be moving from Los Angeles to San Francisco, with many losing their
  jobs.  [Conflicts, turf battles, consulting firms, temporary employees]

  The bank's first public acknowledgement of the problems came in July 1987.
  [See RISKS-5.16]  An in-house investigation was viewed by many staff mem-
  bers as a witch hunt.  The bank announced further costs and then the trans-
  fer of the accounts in January 1988.  [See RISKS-6.16]

  The bank's one-time head of the program, since resigned, says, "A lot of
  people lay down on the floor and spilled blood over this system, and why
  they abandoned it now I cannot understand.  A guy called me this morning 
  out of the blue and said that 95% of it was working very well."



Voice-print security (and Rory Bremner)

J M Hicks <cudat@DAISY.WARWICK.AC.UK>
On Saturday 20th February, the B.B.C. Radio 4 programme "Money Box" broadcast
an item about a service provided by a bank in Britain.  (I didn't catch the
name of the bank --- a pity.)  The service is provided by telephone.  No
mention was made about any kind of secret personal code to confirm the identity
of a customer --- security is afforded by the bank's computer's memory of one's
"voice-print", i.e. it can tell who you are just by listening to your voice.
I believe "funds transfer" is one of the services provided.

    The representative of the bank was asked about the possibility of someone
impersonating a customer.  He replied that the bank had engaged Rory Bremner,
a well-known mimic, to try to mimic other people and deceive the computer.
Rory couldn't.

    Suppose someone recorded someone else's voice and played that down the
telephone line?  (I think the recording would have to be made while the victim
was using the service, though --- after speaking each digit to the computer one
has to wait for a confirmatory beep.  Ordinary fluent speech would not do.)

    What do readers think of the idea of dispensing with the secret
personal code?

(Respondents should bear in mind that few people in Britain have telephones
with multi-tone dialing.)

J. M. Hicks (a.k.a. Hilary),
Computing Services, Warwick University, Coventry, England. CV4 7AL
On JANET:  cudat@UK.AC.WARWICK.CU (in the U.K.)
On uucp:   ...!ihnp4!mcvax!ukc!warwick!cudat

    [Distressing to see the old argument, "Our best forger couldn't break
    it, so it must be pretty good."  Voice-prints are difficult to mimic by
    voice, but easy to spoof by playback attacks.  On the other hand, 
    personal codes (PIN numbers) are also not wholly dependable.  RISKS 
    readers know by now that just about every attempt to gain user
    convenience has some intrinsic vulnerabilities.  PGN]


Auto-mated Citations

Mark Brader <msb@sq.com>
Mon, 15 Feb 88 22:13:02 EST
Following are excerpts from a Usenet discussion going on in the newsgroups
sci.electronic, rec.autos, and (!) rec.ham-radio.  The excerpts were selected,
sequenced, and forwarded to RISKS by Mark Brader.

John Moore (john@tower.UUCP):

  Here in Paradise Valley, Arizona, we have the dubious distinction of
  being the only place in the US where speeding tickets are given by
  mail after an automatic device snaps your picture and speed!

Norm Strong (strong@tc.fluke.COM):

  Most countries in the world hold the owner responsible for
  speeding, regardless of who's driving.  This isn't possible
  in the US because we have a constitution that prohibits it.

Richard Welty (welty@sunbarney.UUCP):

  This* proves to be alterable via local statute.  Communities that are
  trying out the robocop have altered their laws so that they may charge
  the owner if said owner refuses to identify the driver at the time of
  the infraction.  I wonder if the owner gets any points from this ...
    [* No, he didn't mean the US constitution -- msb]

Ron Natalie (ron@topaz.rutgers.edu):

  I was wondering when someone was going to bring up the question of
  "it's not me driving."  I have no idea how Arizona deals with it, but
  a friend who was stationed in Germany told he how it is dealt with there.
  If the driver in the picture is not positively identifiable as you, they
  will let you off on the provision that you log whereever you drive.  Hence,
  if you get your picture taken again, you will have a before the fact
  record of if you were there.  Not keeping your log truthfully is a
  serious offense.

Mad Matt Schaefer (matt@cs.wisc.edu):

  I've heard of this system in Europe (Germany?) and somebody told me that it
  became unpopular with government officials and other important people because
  the ticket and picture came in the mail while the guy was at work and his
  wife opened it and saw the picture of the car, plate, speed, husband, and
  *the other woman* in the car with him. I thought, "this guy is not gonna get
  the welcome he is expecting when he gets home."


Re: Shuttle Security

<mnetor!utzoo!henry@uunet.UU.NET>
Sat, 20 Feb 88 18:44:47 EST
> ... 7 packages of microfilm classified "Confidential" were left
> unsecured for 8 months.  Each package of microfilm contained 181 sheets,
> listing 4,205 confidential radio frequencies ...
> What does this do to a risk analysis of shuttle safety? ...

Probably nothing much.  There is NO SUCH THING as a "confidential radio 
frequency" if it is in active use.  It's just not that hard to eavesdrop
enough to find out which frequencies are being used, and make good guesses
about what they are being used for.  (For example, triangulation will tell
you which transmissions are coming from the range-safety transmitters.)
The real security of the system rests on the secret codes used to trigger
action, and on the difficulty of outshouting the range-safety transmitters
(which send continuously at high power to make it hard for a false signal
to be heard).  Refusing to publish the frequency is just an extra obstacle,
and not a very important one.

This whole thing sounds like a tempest in a teapot, actually.  "Confidential"
is not a very high classification.  Long odds that nothing of real importance
was in those microfilms.

Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry

Please report problems with the web pages to the maintainer

Top