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