Monday, August 11, 2008

Technology for Lawyers and Paralegals: Evidence Authentication - Word Documents

Question

Electronic evidence presents unique authentication challenges. What are the specific issues for MS Word files?

Judge Grimm on Evidence


On May 4, 2007, Chief U.S. Magistrate Judge Grimm provided a detailed analysis of evidentiary issues associated with electronic evidence.

As Electronic Discovery Law explains, in Lorraine v. Markel Am. Ins. Co., 241 F.R.D. 534 (D. Md. 2007), the parties filed cross-motions for summary judgment but failed to comply with the requirement of Rule 56 that they support their motions with admissible evidence. Chief United States Magistrate Judge Paul W. Grimm denied both motions without prejudice to allow resubmission with proper evidentiary support.

In his memorandum opinion, Magistrate Judge Grimm remarks that "considering the significant costs associated with discovery of ESI, it makes little sense to go to all the bother and expense to get electronic information only to have it excluded from evidence or rejected from consideration during summary judgment because the proponent cannot lay a sufficient foundation to get it admitted."

Technical homework

The following discussion uses MS Word documents as an example, but it is applicable to most other documents types.

There are two types of data: document data (words, formatting, etc), and metadata, or data about data. Furthermore, there are two types of metadata: application metadata (title, author, last saved by, etc., even custom fields), and OS metadata (file creation date, file last modified, and more).

To verify the document data together with its metadata, it is possible to compute and record the document's MD5 or SHA signature. Since the application metadata is stored in the file, it too will go into the hash calculation.

For the OS metadata, one can rely on the collection procedure, which hopefully has been done with a validated tool for the best defensibility.

Lacking this, one may go back to the original and use a safe metadata viewer to pull the original OS info (assuming that it has not been modified in the meantime). One can use a tool like Pinpoint Metaviewer to create screenprints for presentation.

For file system metadata one can create a container (such as a zip file) with all the authenticated files together, and compute the signature of the archive. If the files have not been moved or touched or opened, this will preserve the OS metadata.

The signatures thus collected can be used to prove that the evidence has not been tampered with. One can ask the opposing side for the same hashes, and if they agree, there is no argument that both are looking at the same evidence.

Legal approach

To quote from Judge Grimm,

"Authentication also can be accomplished in civil cases by taking advantage of FED. R. CIV. P. 36, which permits a party to request that his or her opponent admit the "genuineness of documents."

If the other side has some doubts about the possible changes in the document, your file hash will prove that both the document and the metadata are intact.

Furthermore, "...at a pretrial conference, pursuant to FED. R. CIV. P. 16(c)(3), a party may request that an opposing party agree to stipulate 'regarding the authenticity of documents,' and the court may take 'appropriate action' regarding that request."

For example, this may be a case where this document has already been under discussion. More generally, once each counsel has exchanged a description of ESI held by a party, one topic for the "meet and confer" can be some form of agreement as to authenticity or at least some stipulation as to what must be done to avoid objections on this basis.

"Similarly, if a party properly makes his or her FED. R. CIV. P. 26(a)(3) pretrial disclosures of documents and exhibits, then the other side has fourteen days in which to file objections. Failure to do so waives all objections other than under Rules 402 or 403, unless the court excuses the waiver for good cause. This means that if the opposing party does not raise authenticity objections within the fourteen days, they are waived."

This is a very important and easier path, since no action is required from the other side.

If the other side produced the document, then, absent special circumstances, this is tantamount to the admission of authenticity.

So far, we have used the FRCP rules. Of course, the arguments are strengthened by proper collection procedure and by availability of hash signature for verification, but strictly speaking these are not required.

The following, more technical, scenarios can use the hashes discussed above:

  1. Presence of the same document (as authenticated by application hash) as an attachment in email from this custodian;
  2. Presence of the same document (application hash) on another computer or laptop belonging to the same custodian;
  3. Presence of the same document (both application and OS hash) in a backup. In this case you will need somebody to testify about the backup procedures.

Note: Legal information is not legal advice. Top8 provides information pertaining to business, compliance, and litigation trends and issues for educational and planning purposes. Top8 and its consultants do not provide legal advice. Readers should consult with competent legal counsel.

The author gratefully acknowledges the editing help and numerous suggestions of Kelvin Rocquemore, Esq., of Trial Solutions.

The author is also thankful to his colleagues at the litsupport discussion group, whose discussions provide him with much inspiration and knowledge.

2 comments:

Jim O'Connor said...

Mark,

Interesting post, and quite timely as well, since issues associated with the authentication of electronic data is increasingly making its way into the news. One point that I think is worth clarifying from this post is the difference between a hash and a cryptographic timestamp. If something is hashed, it can be subsequently altered and rehashed. Such a change is generally not detectable. This is not true of a cryptographic timestamp. A cryptographic timestamp cryptographically binds a trusted time value to a hash and can prove when the data was secured and that it has not been altered since.

In his opinion, Grimm specifically speaks to the value of timestamps in the authentication of electronic evidence, making the distinction above important for your readers who are identifying and implementing tools and processes to achieve authentication.

In case you are interested, here are some additional resources on cryptographic timestamps, and also our analysis of Grimm’s opinion in Lorraine v. Markel:

http://surety.com/individuals/category/secure_hashing

www.surety.com/images/whitepapers/Lorraine_v_Markel_Summary_Analysis.pdf

Best,
Jim O’Connor
Surety, LLC
www.surety.com

Mark Kerzner said...

Jim, that is a very valuable insight. Indeed, if the side that holds that hash is the same side that holds the document, there is not much value in that. Cryptographic timestamps seems to be a much better fit.

I am planning to address this and similar issues in my following newsletters, and I would be interested in your comments.

I agree with your key statement, that is something can be hacked by the application developers or admins, it is not trustworthy. My plan is to show how easy it is to hack things, and from here to prove that it is not as trustworthy as it seems.

For example, if you can find another document with the same hash, then you can substitute this document for the original. True, random clashes are rare. But finding them through directed search is possible.