I Did Not Write This Document And Can Prove It! - A subjective view on why non-repudation is non-existentJ. OquendoC|EH, CNDA, CHFI, OSCPSGFA, SGFE, CSDP*joquendo@e-fensive.net

Companies, lawyers, lawmakers, law enforcement agents, risk managers, security experts and countless others have used the term “non-repudiation” for some time. Many would believe it to be the “Holy Grail”, as proof positive that someone sent something and this fact cannot be disputed. Rather than re-invent any (word) wheels, a little wikipedia snippet is in order:

Non-repudiation is the concept of ensuring that a party in a dispute cannot repudiate, or refute the validity of sending information – be it an electronic statement or signature. Although this concept can be applied to any transmission, including television and radio, by far the most common in the computing realm, is the verification and trust of signatures.

According to traditional legal practice, a signature on a paper contract or memorandum may always be repudiated by the signatory. Such repudiation may take one of two forms: The signatory may claim fraud or forgery, such as "I did not sign that." Alternately, he/she may accept the signature as authentic but dispute its validity due to coercion, as in the scenario of blackmail or confessions given under torture. The legal burden of proof differs depending upon the repudiation reason. In the former scenario the burden of proof typically rests on the party claiming validity, while in the latter it shifts to the signatory claiming lack thereof. [1]

With technology being what it is, non-repudiation based disputes should be well thought through from an argumentative standpoint. This statement mainly applies to those who depend on the term “non-repudiation” for legal purposes, as I cannot see one losing sleep over their co-worker, family member or someone who is not going to disaffect one's financial posture, taking a matter of “non-repudiation” to court. However, what does refuting “non-repudiation” mean on the legal front? How can one dispute the so called “indisputable”. Facts being what they are, one can dispute “non-repudiation rather easily.

From the technology perspective, we know factually that attacks have risen over the years. We can see that new attack vectors gain ground almost daily. Viruses, worms and all sorts of malicious programs make their way into the most hardened systems. Everyone is vulnerable, many are compromised. With this fact in mind, we can look at the most extreme form of “non-repudiation” based communications and dispute this concept of “non-repudiation as well. In fact outright repudiate most electronic forms of communication at will, with denial being either/or: willfully or unknowingly. With that said, I will introduce (or re-introduce) you to PGP based messaging, for which FFIEC states:

A major benefit of public key cryptography is that it provides a method for employing digital signatures. Digital signatures enable the recipient of information to verify the authenticity of the information's origin, and also verify that the information is intact. Thus, public key digital signatures provide authentication and data integrity. A digital signature also provides non-repudiation, which means that it prevents the sender from claiming that he or she did not actually send the information. These features are every bit as fundamental to cryptography as privacy, if not more.

A digital signature serves the same purpose as a handwritten signature. However, a handwritten signature is easy to counterfeit. A digital signature is superior to a handwritten signature in that it is nearly impossible to counterfeit, plus it attests to the contents of the information as well as to the identity of the signer.

The fundamental flaw of that statement by FFIEC is that - an attacker need not counterfeit a signature to repudiate sending a message. Why should they counterfeit a signature when they can validly sign a message as a sender? Surely that would be irrefutable proof that a sender did indeed send a message. Even if the key was created during a PGP key-signing party there is little to validate the authenticity of the sender. "The agencies consider single-factor authentication, as the only control mechanism, to be inadequate..." From the FFIEC "Authentication In an Internet Banking Environment" [3]

A visual would look as follows [EFNR]. In this instance, a fictitious character named John Smith created a PGP key in front of hundreds of users. He created a 4096 bit key so another fact based snippet is in order: As of 2008, the largest (known) number factored by a general-purpose factoring algorithm was 663 bits long (see RSA-200), using a state-of-the-art distributed implementation. The next record is probably going to be a 768 bits modulus. RSA keys are typically 1024–2048 bits long. Some experts believe that 1024-bit keys may become breakable in the near term (though this is disputed); few see any way that 4096-bit keys could be broken in the foreseeable future. [4]

We can allude to John Smith being the sole sender of any messages signed and sent by him using the key he created – theoretically. Because many individuals prefer simplicity over complexity, certain attacks – if I can even call them that – come to mind where this concept of non-repudiation is mentioned. No matter what the key size is or security protecting information is, it all gets thrown out the door when it comes to technology.

In most businesses, high powered executives have assistants under them. Think about this for a moment. What happens when an executive who almost always is mandated to digitally “sign” business based emails prior to sending shares his PGP keys? Most executives will likely have their assistants sign on their behalf, and they will not know of the dangers involved with giving out their password. In these businesses, it is very likely that executives have literally given away their fingerprint in the form of passing to their assistants the pass phrase to their PGP keys: “Oh, you need my fingerprint to send that email. Before you send it, might as well write this down so I won't have to remind you. The pass phrase is MyFavoriteSportsTeam. Make sure you put it somewhere you will always find it. Under your mouse pad, no one would ever stop to look there.” If you think it doesn't happen, apparently you haven't work in many large environments.

Secondly, there is caching. For those unfamiliar: “a cache is a temporary storage area where frequently accessed data can be stored for rapid access.” Many PGP-like programs have options available for caching. They do so for ease of use. “Remember my password for n amount of minutes so I won't have to re-type it”. Much has been written on cache attacking, timing attacks (TOCTTOU), so there is no need for a barrage of snippet explanations on these attacks. These attack vectors exist whether one realizes it or not. Thirdly, copy and pasting: We've already seen the insanity of web pages being able to access what is on the clipboard–you know, the placewhere things get stored when you copy them. [5] Finally, there are malicious programs, many of which are known to upload keystroke loggers to a machine. In light of this fact, we observe the following:

In the pictured instance [EFNS], from the outside perspective, John definitively sent a threatening e-mail. It's obvious as hundreds of witnesses were present when he created a PGP key. In fact, hundreds signed his PGP key so there is no way he could “not” have sent that message. Fact: There is no method to counterfeit a key. Fact: An attacker need not duplicate a key to forge an e-mail and sign it provided the attacker has access to the password. Facts being what they are, we can see the possibility of John Smith not even sending a threatening message - contrary to the pulpit pounding “guilty-as-charged” non-repudiation charges lobbed at him. So the question would then become: “Why would someone do such a thing” which leads to a brief introduction on a “Joe Job” [6], or in military terms, the false flag [7]:

“False flag operations are covert operations conducted by governments, corporations, or other organizations, which are designed to deceive the public in such a way that the operations appear as though they are being carried out by other entities”

The Internet can - and has proven at times to be - a wild west. A place where anything goes. We have read about “cyber-bullying” and “cyber-warfare,” and the list goes on. So “cyber-framing” should not be any different. In fact, it should be looked into rather than being passed off. Facts are facts, whether we accept them or not. This concept of refuting non-repudiation is not anything new. In fact, the concept was re-introduced to me while I sat in Dulles Virginia by a great instructor I had while taking CISM (Certified Information Security Manager) courses. (Thanks Larry) Captain Kirk voice: “Spock... Can it... be... that... you did not.... send... that...message?!”

While I had previously written an article in the early part of this millenium called “Framing Private Ryan” that meticulously detailed the dangers involved with “cyber-framing” and electronic attack vectors, the purpose of the initial write-up was to stir up conversation about the validity of electronic data as a source of “evidence”. For matters known to me and to those that know me, I'm all for accountability - so much so now - more than I ever was. I know first-hand how one's life can be turned upside down by those who don't really understand technology, and the dangers associated with data being used as evidence. In dealing with explaining technology, technology is far more prone to tampering than many actually realize and it can be a trial in itself sorting out the truth. Hence, here it is eight years later and again I am re-iterating the need for people to re-visit this topic.

In the years prior to “e-signatures” it would have been difficult to dispute the fact that someone signed a document or came into agreement on, say a contract, since there was a physical element involved. It was “your word against someone else’s.” With electronic information, however, it is not as clear cut. We can assume that John Smith sent a message; in fact, most evidence will tell us this. Yet if we dig deeper into the electronic forensics scope, we can prove factually that, while someone could not have possibly counterfeited a PGP key, we can still repudiate sending a message.

There is little to argue on the point of breaking encryption however, since many are still taking the wrong approach from an argumentative standpoint – we know crypto cannot be broken - so it would be absurd to question the legitimacy of non-repudiation from a technological standpoint when the question is “can you break crypto?” Especially when the person on the stand is holding a PhD and is stating: “The cryptography goals are: privacy or confidentiality, data integrity, authentication and non-repudiation.” [8] Who are we to argue? It is one Subject Matter Expert versus another. But don’t believe everything you see, especially when it comes to electronically obtained information.

Electronic information is and will continue to be insecure no matter what safeguards we choose to use in order to protect them from disclosure. I havve read countless books, request for comments, white papers and arguments on the subject yet everyone seems to point back to technology solving another technological problem. It is sort of difficult to fathom given that a computer can only output what one inputs. My personal favorite acronym for the moment is “CBVA,” which means Complexity Based Vulnerability Analysis. Sounds mystifying--wouldn’t you agree? But, when looking at that explanation closely, the end result will always bring us back to square one, there is little guarantee:

One goal of our effort has been the development of complexity-based vulnerability analysis (CBVA), utilizing a complexity-based information assurance metric for vulnerability analysis. The metric proposed is based upon Kolmogorov Complexity. Computable estimates of this Kolmogorov Complexity have been indicated, as well as additional useful applications of Kolmogorov Complexity for communications in general. Unless vulnerabilities can be identified and measured, the information assurance of a system can never be properly designed or guaranteed. [9]

Scenario: On trial is John Smith for sending PGP signed death threats to a politician.

Prosecutor: Is say a 4096 bit PGP key vulnerable?Expert: (Inserting random fluff mathematics which will bore a jury) ... in short, it is impossible.

Prosecutor: So you’re saying there is no method to counterfeit a PGP key--correct?Expert: That’s correct.

Prosecutor: So it would be safe to say that any message that was signed with that key would have been sent by whomever was in possession of that key?Expert: That is correct

Prosecutor: Can I repudiate this?Expert: Experts from all over the world have been trying to break these algorithms and have been unsuccessful, so it's doubtful.

Prosecutor: So without reasonable doubt, you’re saying someone couldn’t have counterfeited this “fingerprint” if you will?Expert: This is correct, I’m absolutely certain.

In this instance of questioning from a prosecutor to an expert witness, the defendant seems to be irrefutably guilty of sending the message. He obviously did not have his key counterfeited, therefore he must have sent that threatening message. Imagine, if you can, your life thrown into mayhem due to a situation like this. What would you do, who would you turn to, how would you defend yourself? How would you protect yourself? “It's your DNA at the crime scene!” The answers are not always clearcut, and sometimes there are no answers. Depending on technology to solve other technological problems is foolish. Yet professionals continue to fool themselves into believing the concept of non-repudiation, which brings us back to the statement in the first paragraph of this page: “Unless vulnerabilities can be identified and measured...” How can you offer a measurement in this scenario? Surely there would likely be more evidence involved with a case like this; however, for those who work in the security realm, you should be mindful of these situations. There are many reasons to keep a sharp eye out for all anomalies on

one’s network--no matter how insignificant they can seem. After all, your fingerprint may depend on it. Anyone working in the forensics field should examine machines carefully for instances of malware, breaches, viruses and the likes.

Getting back into the courtroom scenario, a counter-argument could work out as follows:

Defense: In order to create and sign this message, a user solely needs to provide a password for sending a message - is this correct?Expert: This is correct.

Defense: Can this password be guessed?Expert: Possibly, although one should use a strong password to avoid this.

Defense: What if the password was compromised--could someone else have signed?Expert: Absolutely.

Defense: So we can dispute non-repudiation, can’t we?Expert: I suppose you can.

Defense: Are you aware of any trojans, malware, infections or anything similar in your years of experience that has say, stolen PGP keys? [10, 11]Expert: No I’m not aware.

Prosecutor: Objection, we can stipulate there have been ...Defense: Defense rests.

Theoretically, all that is needed is reasonable doubt. At this point it is created. The introduction of known threats, viruses, malware and the potential that this “could have” occurred should be enough even to absolve someone who is guilty. A dual edged sword, wouldn't you say? Yet as investigators, security professionals and forensic experts, we could have taken the due diligence to check for this prior to an encounter like this.

Let us move more into the forensics arena here: The argument being either to prove or to disprove that an infection on John Smith's machine caused a password to be compromised, which led to the threat message being signed and sent. Reality being what it is, can we prove statistically, beyond a reasonable doubt, that infectious programming is on the rise? Can we correlate an infection to a password being compromised? As a forensic expert, have you performed your due diligence, have you checked for this?

A thorough examination of a machine with an infection (malware, viruses, etc.) has the potential to either make or break a case, given what I've already presented. You do not necessarily need to break technology, especially one that cannot be broken and yet one can still circumvent it. So, for those who study and read about non-repudiation and associate this dreaded term as being as concrete as a fingerprint or DNA - “the silver bullet” - I say to you: “You might be thinking solely with your keyboards and not using your brains here!”

Surely, from an offensive posture, arguing this case (for non-repudiation) would be a difficult one, and very time consuming. Yet, in the event that an argument like this sprouted, questions that I would immediately focus would be the attention paid to the state of the machine with regards to malware, viruses, etc. Anyone in the forensics field will tell you that it is a difficult task capturing registry states from a forensic standpoint. Even more so with malware, where it is becoming

much more difficult to detect and decipher it. What is the next move? Where do we go from here? Should we really continue using the term “non-repudiation”?

Four years ago, while pregnant, Ms. Amero went to work one day as a substitute teacher and left with felony charges against her.

Her crime?

Julie Amero was convicted of four felony counts, each count carrying a maximum of ten years, for exposing school children to pornography.

The reality is that Julie, a 40 year–old, pregnant substitute teacher, found herself in a storm of popups and didn’t have any idea as to what was going on, or how to fix the situation.

...

In March 2008 a $2,400 ad appeared in the Hartford Courant which was signed by 28 computer science professors arguing that Ms. Amero could not have controlled the pornographic pop-ups. Trial Detective Mark Lounsbury never checked for the presence of malware.

A number of computer security experts, led by software developer and blogger, Alex Eckelberry noticed serious technical errors were made throughout her trial. Mr. Eckelberry brought together a group of forensic investigators who volunteered to analyze the computer hard drive she was using in the classroom that day and published a report on their findings.

The group's report ultimately caused Julie's conviction to be overturned. Judge Hillary Strackbein overturned the unjust verdict in 2007 and ordered a new trial because of erroneous and false information given during the initial trial. [JAM]

There are those who will say: “You're insane! That only happens on television or in works of fiction” and to those people I would like to make reference to “GETTING EVEN The Truth About Workplace Revenge—And How to Stop It.” [ISBN 978-0-470-33967-1]. Here is what I am trying to convey: Information, when used as a means of evidence, should not be relied upon as many in the legal arena are quick to call a “silver bullet” or homerun. Forensics, from a physical perspective, is simpler to prove than that of electronic forensics. While not always fullproof, someone attempting to spoof (mimic) someone else's fingerprint along with, say a hair follicle, is outright far-fetched. While in certain scenarios, that too can be pondered. Who is to say that your insane neighbor who hates you, did not go into your barbershop after your haircut and offer to sweep the floor (as strange as that may sound) in order to get some of your hairs to leave at the scene of a crime? Far-fetched, sure, but still achievable and while not that plausible, it should not be discounted.

Electronic forensics is an altogether different ballgame from the normal forensic sciences though.

Unlike normal criminal forensics, there is plenty of physical evidence which is much more difficult to “plant.” We know that in recent years there has been a surge in “anti-forensics” applications and methods which make the “barbershop” hair scenario a lot simpler to achieve on the technological scope and it can accomplish this in a much more covert fashion. This is what makes the reliance on digital forensics such a danger. We are not looking at physical evidence; rather we are looking at electronic bits (ones and zeros), which can easily be manipulated. Not only can this evidence be manipulated maliciously, but also inadvertently by investigators or anyone else involved with the electronics.

Let us look at the six phases of the digital forensics process [12]: Identification, Preservation, Collection, Examination, Analysis and Presentation. We can closely examine the danger in relying on all or any of these from an investigative standpoint. Here are some of the concerns I would have while doing an incident response, with an explanation associated for each concern:

1) Identification – In order for an investigation to take place, an attack would have to have been identified. It is extremely doubtful that someone stumbled upon an active intrusion or incident. We can rightfully say that some mechanism of logging or an event trigger took place and alerted us to an anomaly, which is now called event_X. With all of the different programs and events on a network, the odds of someone watching log information in real-time and seeing an active attack, would be the equivalent of a needle-in-a-haystack search. Only in the case of electronics, this haystack would stretch for miles.

Log validity is not always a clearcut approach to validating the identity of an individual. All we can verify is, “this came from machine_A's IP address”. While we can correlate an IP address to a MAC, the MAC to an IP, then to a machine, followed by a port on the switch, we cannot rightfully state that John Smith sat at his computer and caused event_X. We do know factually that we have a log entry of event_X that was triggered by the IP address that matches the machine that John Smith uses. Our first approach to skepticism comes from the fact that IP addresses are easily spoofed. There is no definitive mechanism to halt this. We can minimize the spoofing of addresses with, e.g., BCP filtering, VLAN's, port security and a variety of other corrective measures, but we cannot rid a network of this definitively. At least, I've not found any product or person who will come flat out and make this statement knowing it can be disputed.

With identification, going a step further, let us suppose that we have a Network Access Control with strategically placed cameras pointing at John Smith's desk, and with timestamps that will assist us so that we can point out factually that John Smith sat at his desk at the exact time that entry_X occurred. Despite that, we still cannot prove positively that John Smith is the culprit. Because of the malware, virus, trojan and altogether “badware” factor, there is the high possibility that something outside of John Smith's actions was responsible for triggering event_X on his machine.

So we place anti-virus, anti-malware and other types of software on his machine to further minimize these instances. We know factually that John Smith's machine is at IP address 10.10.10.2 because our switches tell us so. We know factually that his machine's MAC address is 00:00:de:ad:ca:fe because his physical hardware tells us so. The cameras tell us he was at his desk all day; his anti-virus and all other installed software have green lights (meaning that they've been updated). So what?

Here are the counterpoints: 1a) MAC addresses can easily be changed [13], yet we can go on and state that “he didn't

have administrative privileges.” We can also dispute this.

1b) Anti*anything* software relies on updates based on “known threats.” In the case of a customized or newly created trojan, unless that signature exists, it will not be detected.

1c) As a forensics investigator, we would need to know how the router and firewall handles traffic—e.g., their filtering (spoofing). Without doing so, anyone can dispute the validity of IP.

1d) Because sysloggers are relying on IP, we need to go back to 1c: IP is unreliable.

2) Preservation – Have we taken the necessary steps to ensure that the chain of command was followed? “James Acme discovered an attack - entry_X. Upon further investigation...” Investigation by whom—James Acme? Does he understand forensics? Does he have the authority and/or knowledge to complete incident response? What was his visibility when doing forensics (meaning: Who else witnessed the initial response? How was the evidence handled and preserved?)

I would like to point out the following comment in an article which I read and commented on pertaining to mobile forensics[13]: “I recommend making a working copy and an archive copy. Now reseal and store your exhibit.” My inference after reading that author's commentary was: A disk storage device of sorts was obtained, forensics were started, at a later time, a recommendation was made. If you take the time to read the entire article, one can instantly interpret the investigator as starting his incident response prior to making a copy of the evidence. “By the way,... you should make a working copy and an archive copy...” One of the first steps, prior to even plugging in any software or hardware, be it EnCase, FTK, or Oxygen, is to make a bit-by-bit copy. This is done way after the picture taking, network mapping and all of the previous steps: Otherwise, you've just tampered with the data and possibly cost someone a trip to the slammer, when they may be innocent!

3) Collection – I associate “Preservation” with this step. I would also emphasize and place “Preservation” again immediately after “Collection.” After the collection of the data, we need to make sure we perform our due diligence and preserve what we have collected. There should never be a moment when you say: “Oh, did I make a copy?” or “Gee, now where'd that copy go?...” The statement: “I recommend making a working copy” is horrific. A better understanding is - making a copy is not a recommendation, but rather an outright mandate! As a forensics investigator, if I were on the stand answering questions against this expert witness (linked in the article), his comment, approach and methods would bring questions into the validity of his evidence not to mention the verification of his evidence. He did not seem to follow standards and procedures. Why should someone's life be placed in the hands of an expert like this?

I would question the methods of collection of the evidence; i.e., how was it accomplished? Was the machine “unplugged” or powered down? Was a live forensics CD used, did the incident response handler have the proper write blocker in place in the bit by bit copy? Who was the responder? Was he or she qualified, and if so, by whom? There are plenty of questions to ask here. Collection methods can be meticulously debunked, especially if they are not properly documented from square one. 4) Examination – Because so many anti-forensics based tools have made headway in such a

fashion that 'anyone without forensics experience can use them,' how trustworthy is the data that we are investigating and analyzing anyway? Did the forensic examiner take all know snapshots and entry points to this machine being analyzed? By this I mean physical images and diagrams of the connectivity to this machine and to its location. E.g., in a cubicle

environment, who else may have access to this machine? Was there a clear desk policy? Were there passwords lingering under the keyboard? Were the firewall rules, router configurations, NAC and anti-virus configurations viewed in order to diagram how information flowed into this machine? Were state sessions taken from the firewall or router to show who or what was connected to the machine upon the time of incident response. This is the best mechanism to validate the trustworthiness of the data we are obtaining, we're validating that there was no outside tampering with any potential evidence on this machine and verifying it prior to moving anything. We have to remember that - one small compromise on another machine in that network - and the “forensic” wall comes crumbling down. There is plenty to ask here.

5) Analysis – What should we look for outside of the obvious (evidence of what caused event_X)? I would dissect our forensics copy and look for any hints of malicious software on the machine (viruses, worms, trojans, rootkits). If an instance comes up, we would need to know if we can associate that as the cause of event_X on John Smith's machine or rule it out. Did we perform due diligence in ensuring we unpacked any discovered “packed” malware? Did we search for extreme anamolies: stegonography, crypto, rootkits? Any one of these could exist. In searching for these instances, we: a) remove the potential of someone disputing our findings and punching holes in our evidence; and b) can show factually that information was not subject to tampering from an outside source.

6) Presentation – I, as an expert, should be sure beyond a shadow of a doubt that event_X was caused by this machine and not John Smith. As a forensics examiner, my role is not to prove who did what, but rather to describe in detail what occurred, how it occurred, and how I discovered its occurrence. It would be too simple to solely connect the dots—MAC to IP to Desk plus Camera Image equals John Smith. The reality however is, it is not that simple. Especially not with technology, and even more so when a life is on the line.

So is it safe to say that electronic evidence needs some revamping? Sure, but the questions are how can we do it and what can we do about certain issues. How and what can we do to prevent problematic questions from catching us off-guard? We have known all along as security professionals that we can place as many detective, corrective, preventive and other controls in place and yet we could still fail miserably. Electronic Forensics, in its short form, has both many pros and many cons. But when someone has their life on the line — possibly due to “digital framing” — we have to work harder to make sure we do not make mistakes. Especially little ones, like: “Oh gosh...maybe I should back this up instead of running EnCase on a live disk. Know what, I recommend backing it up...” [3]

[1] http://en.wikipedia.org/wiki/Non-repudiation[2] http://www.pgpi.org/doc/pgpintro/[3] http://www.ffiec.gov/pdf/authentication_guidance.pdf[4] http://en.wikipedia.org/wiki/RSA[5] http://msdn.microsoft.com/en-us/library/bb250473(VS.85).aspx[6] http://en.wikipedia.org/wiki/Joe_job[7] http://en.wikipedia.org/wiki/False_flag[8] Handbook of Research on Information Security and Assurance Chapter XI (ISBN 978-1-59904-855-0)[9] http://www.stat.ucla.edu/~cocteau/dimacs/bush.pdf[10] http://isc.sans.org/diary.html?storyid=4207

[11] http://lists.jammed.com/ISN/1999/02/0007.html[12] http://en.wikipedia.org/wiki/Reasonable_doubt[13] http://www.technitium.com/tmac/index.html[14] http://mobileforensics.wordpress.com/bio/[JAM] http://www.huffingtonpost.com/kim-mance/teachers-pop-up-porn-nigh_b_145772.html[EFNR] http://www.e-fensive.net/non-repudiation.jpg[EFNS] http://www.e-fensive.net/repudiation.jpg

Special thanks to: David Litchfield, for sending me more information to read; Joel Gridley, for reminding me that I am officially a dinosaur, as well as sending me banking regulatory information; Larry Greenblatt, for being one of the most down-to-earth security professionals I have ever met; Chris Nickerson and others, for tuning in and promoting the Exotic Liability podcast (NOTE: Keep thinking outside those boxes!); Dr. Anton Chuvakin, for his input which led to additional clarification on my stance concerning this topic (repudiation versus non-repudiation); Susan Cascio, for spending so much time reading my documents and for forcing me to relearn horrible 'engrish' [sic] and grammar. Ron Herrmann for assisting me in re-writing portions in an understandable fashion and especially, to my wife for tolerating me.