Forward: Tim McVeigh trial info from RISKS DIGEST 19.19 (fwd)

[Paul Bradley <paul@fatmans.demon.co.uk>]

The following may be of interest to those following the Tim McVeigh OKC 
trial, it relates to technical flaws in the evidence relating to the 
telephone debit card McVeigh allegedly used.
	
        Datacomms Technologies data security
       Paul Bradley, Paul@fatmans.demon.co.uk
  Paul@crypto.uk.eu.org, Paul@cryptography.uk.eu.org    
       Http://www.cryptography.home.ml.org/
      Email for PGP public key, ID: FC76DA85
     "Don`t forget to mount a scratch monkey"

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

Date: Wed, 28 May 1997 11:47:43 -0700 (PDT)
From: hbaker@netcom.com (Henry G. Baker)
Subject: Oklahoma bombing trial transcripts

RISKS readers may find the following transcript from the OK bombing trial
to be particularly interesting:
  http://www.cnn.com/US/9703/okc.trial/transcripts/may/050697.eve.txt
(Note CNN's Y2K problem, but that's for another time!)

This transcript was brought to the attention of another usenet group due to
its details of how the debit-card business works.

The bulk of this transcript deals with the testimony of a Mr. John Kane, an
executive of the company that handled the telephone debit card that was
allegedly used.

Problems:

There was no one computer that had all of the information necessary to
connect a phone debit-card number, the phone number from which a call was
made, and the phone number to which the call was made.  3 different logs
from 3 different computer systems whose clocks were not synchronized must be
related in order to determine this information.  Therefore, it is difficult
to relate the logs in an unambiguous manner.  Furthermore, the logs indicate
only a physical port number, and the only way to determine the
correspondence is to _physically inspect_ the connectivity of the cables.

Q. How often were the cables rearranged?  Since the system would work fine
with a different permutation of the cables, what assurance do we have that
the cables had not been rearranged by a technician who many never have told
anyone, or not even realized himself?

Due to the large sizes of these files (2.5 billion calls!), the 'matching'
process allowed for +/- 4 minutes 'slop' in comparing the clock times of the
different logs.  Q.  Did they take into account Daylight Savings Time
(especially given the problems we're recently been talking about)?

Q. Did they take into account the fact that on different days the clocks may
have had different discrepancies?

There are key items missing from the most important transaction log.  This
is because this computer was _intentionally rebooted_ 3 times every day
(perhaps at midnight, 8AM, 4PM, all Los Angeles time).  Each time the
computer was rebooted, some transactions were lost; whether from not having
been saved from the write buffer, or not being logged during a length boot
process, was not made clear.  Apparently, a very critical phone call was one
of the transactions that were not logged due to this rebooting.  (What are
the chances of this??)

Why was this computer rebooted 3X per day?  Because it had apparently been
crashing of its own accord prior to this, and those crashes had been very
inconvenient, so it was decided that purposely rebooting would result in
fewer complaints.  This rebooting may have resulted in a slight loss of
revenue, as well, as the missing calls may never have been logged.

There is a presumption that if a PIN (in this case a 14-digit PIN) is being
used, that only one person could possibly have used it.  However, apparently
this system did not check to see that multiple people (perhaps in different
parts of the country) were not using the same PIN number at the same time.
(Unlike many prepaid phone cards in Europe, there is no physical card to
plug into the phone -- the _only_ proof of identity is the PIN.)

Henry Baker  ftp://ftp.netcom.com/pub/hb/hbaker/home.html