Minnesota Computer Forensics and Legal Technology


Introduction

Over the last several years, I’ve posted a handful of short blog entries about the topic of compelling a criminal defendant to surrender a passphrase to an encrypted volume or hard-drive.  These entries concern the three cases of re Grand Jury Subpoena Duces Tecum Dated March 25, 2011, United States v. Fricosu, (D.Colo, 2012), and In re Grand Jury Subpoena (Boucher), 2009 U.S. Dist. Lexis 13006 (D. Vt., 2009).

I have developed the opinion admittedly, more on hunch than scholarly researchthat a defendant should not be able to knowingly withhold a passphrase or password to an evidence trove any more than he should be permitted to hang on to a physical key that could be used to open a safe that the Government has a valid warrant to search, and which is believed to contain evidence.

Unfortunately, I have found myself on the wrong side of this issue.  My colleagues Sharon Nelson and Craig Ball disagree with me on some aspects of the issue.  And my position is seemingly at odds with the Eleventh Circuit in Grand Jury Subpoena Duces Tecum Dated March 25, above, a decision that Professor Orin Kerr described as mostly correct (although I note that the Eleventh Circuit did distinguish Boucher, and recognize exceptions).

Privilege

Setting aside, for the sake of this comment, the question of whether knowledge of the passphrase is both “testimonial” and “incriminating” for purposes of the Fifth Amendment (the very issues central to the aforementioned cases), or whether the knowledge of the passphrase should be distinguished from possession of a physical key, my belief has been based on a principle that parties to either criminal or civil litigation should simply not be permitted to purposefully withhold admissible evidence from each other. Professor Arthur Miller, the great civil procedure legal scholar calls this the “cardinal, basic, philosophical principle.” “Since we’re trying to get at the truth,” he continues, “You must give every litigant equal access to all relevant data . . . It’s as American as apple pie.” Arthur R. Miller, Civil Procedure, Sum & Substance audio lecture series (1999).

Now, before I continue, let’s recognize I have purported to be an axiom for what it is:  incorrect.    In fact, there are several basis under our system of law when a party is permitted to withhold otherwise relevant, admissible evidence.  We call it “privilege.”  Privilege is that annoying rule of law (I’m being facetious here) that, “to protect a particular relationship or interest, either permits a witness to refrain from giving testimony he otherwise could be compelled to give, or permits someone (usually one of the parties) to prevent the witness from revealing certain information” Waltz & Park, Evidence, Gilbert Law Summaries, § 635. Perhaps the most common example of it is the attorney-client privilege. See Upjohn Co. v. United States, 449 U,S, 383, 389 (1981) (acknowledging the attorney-client privilege as “the oldest of the privileges for confidential communications known to the common law”).

But even the hallowed attorney-client privilege has its limits.  Under the civil fraud and criminal fraud exceptions, an otherwise privileged communication becomes discoverable. See, e.g., United States v. Zolin, 491 U.S. 554, 562–63 (1989) (stating goals of attorney-client privilege are not served by protecting communications made for purpose of getting advice for commission of crime or fraud). And see Deborah F. Buckman, Annotation, Crime-Fraud Exception to Work Product Privilege in Federal Courts, 178 A.L.R. FED. 87, § 2[a] (2002).

Encryption as Evidence Destruction

Craig Ball often reminds his audiences of the three ways to destroy electronically stored information: (1) overwrite the bytes with new data; (2) physically destroy the media upon which the data was written; or (3) use strong encrypt on the data and forget the passphrase.  Thus, in my assessment, if an individual encrypts evidence while engaging in the commission of a crime, it is tantamount to flushing drugs down the toilet, throwing the murder weapon in a lake, or silencing a witness. These are independent criminal acts, separable from the underlying charges.   Likewise, a civil litigant, who encrypts evidence after the duty to preserve has attached (articulated best in Zubulake v. UBS Warburg, 220 F.R.D. 212, 218 (S.D.N.Y. 2003)(“Once a party reasonably anticipates litigation, it must suspend its routine document retention/destruction policy and put in place a litigation hold’ to ensure the preservation of relevant documents”)), engages in spoliation that may be punishable.  Therefore, I contend, by using encryption, a defendant or litigant may engaged in spoliation of evidence albeit undoable which may be subject to independent criminal liability, civil sanctions, or an adverse jury instruction.

Notice, these phrases in bold, above, establish mens rea, (i.e., intent — purposeful or knowing conduct) that the actor was using encryption in the furtherance of a crime, or to destroy evidence to thwart a law enforcement investigation.  An instructive analog may be the safe harbor provision, Fed.R.Civ.P. Rule 37(f), as applied to electronic discovery in civil cases. The provision shields a party who cannot produce evidence lost as a result of the routine, good faith operation of an electronic information system. In other words, if an individual was using whole-disk encryption not to obfuscate criminal activity, but rather because he was trying to protect against identify theft, or because the system came with it by default, there is no intent, hence no criminal culpability. Another helpful analog might be found in Arizona v. Youngblood, 488 U.S. 51, 58 (1988), where the U.S. Supreme Court held charges may be dismissed based upon evidence lost or destroyed by the Government, which is deemed to be only potentially exculpatory (as opposed to apparently exculpatory), only if defendant can show the evidence was destroyed in bad faith.

But, perhaps the best authority addressing the mens rea requirement is probably that required for the 18 U.S.C. § 1503 (conduct that, among other things, corruptly endeavors to obstruct or impede the due administration of justice): To sustain its burden of proof, the government must show that the defendant knowingly and intentionally undertook an action from which an obstruction of justice was a reasonably foreseeable result. Although the government is not required to prove that the defendant had the specific purpose of obstructing justice, it must establish that the conduct was prompted, at least in part, by a corrupt motive.” United States v. Barfield, 999 F.2d 1520, 1524 (11th Cir. Ala. 1993) (internal quotations omitted).  Unlike the duty-to-preserve in civil cases, which requires only reasonable anticipation of litigation, the federal criminal context requires there to have been a pending judicial proceeding known to defendant at the time. See, e.g., U.S. v. Fineman, 434 F. Supp 197 (E.D.Pa 1977) (In applying the obstruction of justice statute to issues of destruction of documents, federal courts generally have not required that a subpoena have issued. Rather, it is sufficient for an obstruction conviction that the defendant knew that a grand jury was investigating possible violations of federal law and intentionally caused destruction of the incriminating document.). In fact, 18 U.S.C. § 1503  has even been applied to prosecute those who, in a civil case, were accused of willfully destroying documents subject to discovery. U.S. v. Lundwall, 1 F.Supp.2d 249 (S.D.N.Y.,1998).

Note that my theory is not that the presence of encryption is somehow admissible as relevant in demonstrating defendant’s mental state or aptitudes, as it appears to have been in State v. Levie, 695 N.W.2d 619 (Minn.App. 2005) (“the existence of an encryption program on [defendant’s] computer was at least somewhat relevant to the state’s case against him,” and the jury was allowed to consider it). See also Jessica Murphy, Swiss Cheese That’s All Hole: How Using Reading Material To Prove Criminal Intent Threatens The Propensity Rule, 83 Wash. L. Rev. 317 (May 2008).  Rather, my theory is that, even if a court finds that a defendant cannot be compelled to aid in his prosecution by surrendering a passphrase (because doing so would be testimonial and incriminating), a defendant may nevertheless be criminally liable for evidence spoliation.  Further, when evidence is spoliated, a factfinder may be entitled to presume that the evidence was unfavorable to the spoliator. See Washington Gas Light Co. v. Biancaniello, 87 U.S. App. D.C. 164, 183 F.2d 982 (D.C. Cir. 1950) (Willful destruction of evidence by a party properly raises the inference that the materials destroyed were adverse to the party which brings about the destruction); Brown & Williamson Tobacco v. Jacobson, 827 F.2d 1119, 1134 (7th Cir. 1987) (“A court and a jury are entitled to presume that documents destroyed in bad faith while litigation is pending would be unfavorable to the party that has destroyed the documents.”); Dale A. Oesterle, A Private Litigant’s Remedies for an Opponent’s Inappropriate Destruction of Relevant Documents, 61 Tex. L. Rev. 1185, 1232-39 (1983) (“[A] party’s bad faith destruction of relevant documents is an admission by conduct that he believes his case is weak and cannot be won fairly.”). See generally 2 John Henry Wigmore, Evidence §291 (James H. Chadbourn rev. ed., 1979) (discussing evidence spoliation).

Conclusion

The right to privacy as, Justice Douglas recognized in Griswold v. Conneticut, arises from “penumbras, formed by emanations from those [specific] guarantees . . . in the Bill of Rights.”  And the Bill of Rights operates as a constraint on the Government.  But, those penumbrae do not, in my view, confer a magical privileged status to file or disk encryption under the rubric of privacy, when, in certain limited circumstances, such encryption is really just evidence spoliation.

As a forensics examiner, I am already seeing and foresee a higher frequency of criminal and civil investigations thwarted by the use of file or disk encryption and the privilege under the Fifth Amendment.  Absent new statutes addressing the misuse of encryption technology, a prosecutor should closely examine the Eleventh Circuit decision to see if his or her case falls under the limited exceptions that would require defendants to surrender the passphrase under the penalty of remedial contempt. Alternatively or conjunctively, prosecutors should determine whether the use of encryption by defendants fall within the scope of an applicable federal or state statute for destroying evidence in the furtherance of a crime, or incident to a criminal investigation, where there is extrinsic evidence of a corrupt motive.

Minnesota Computer Forensics and Legal Technology


Introduction

In this post, I will provide some initial impressions and findings.  I do not  endeavor to write a white paper, or to employ an industry standard, scientific methodology to evaluating the tool (if for no other reason than because I am constrained by time).

 

PostgreSQL

First, I note that it appears that no one has been able to get FTK to work with PostgreSQL, leading me to conclude that the product was shipped without being tested in this regard.  (If a reader has been able to get it working, I encourage you to post a comment here).   I was not able to get it to work, and I wasted two valuable —otherwise billable— days I had set aside for a client, only to make this discovery.

My review of the AccessData forums indicates identical experiences, and I haven’t found one poster there who yet claims to have finished an evidence load using FTK with Postgres.  (Note: I am unable to determine whether it is an AccessData use-violation to excerpt comments from the private forums, so I am proceeding with an abundance of caution by not doing so).

Likewise, I conferred on Friday with another colleague, a lead examiner for a large company, and he replied:

I just had the same experience. I mistakenly upgraded to 4.0, removed Oracle completely, and installed PostgreSQL. That was a mistake . . . some of my run-of-the-mill cases that should only take a couple hours were taking days and had to be killed off. Then, after I removed PostgreSQL and re-installed Oracle I couldn’t get it to forget about the old connection and had all sorts of weirdness with it not finding Oracle some of the time. I eventually backed out FTK, Oracle, and PostgreSQL and did a complete manual cleanup of all garbage files and registry entries and then re-installed everything. I am back to Oracle with 4.0 and things are fine again, but what a mess to deal with this on 3 machines.

And, the same experiences are found on the ForensicFocus forums (e.g., http://www.forensicfocus.com/Forums/viewtopic/p=6557533/).  Thus, based solely on these numerous anecdotes, and based on my understanding that new purchasers of FTK do not receive Oracle licensing, I have concluded that FTK 4.0 & Postgres is not merchantable (suitable for its intended purpose), although –as noted above– I may be incorrect, and would be pleasantly surprised to be proved wrong.

So, I, too, reverted back to Oracle.   Unfortunately, I couldn’t get the Oracle KFF library for v4.0 posted on AccessData’s FTP site to work.  In browsing through the AccessData forums, neither could anyone else.  AccessData made available to me and certain others who complained a working KFF, which –last time I checked– is not the one available for download at the AccessData FTP site.

Now, like many of the others who have posted to the AccessData forums and elsewhere, I am able to use v4.0 with Oracle.

 

Hardware

The three machines I used for testing are, as follows:

(1)  FTK & Oracle server (one box) – SuperMicro X8DTL-6F motherboard, LSI SAS2 2008 controller, two RAID-0 volumes each consisting of two OCz Vertex 3 Max IOPS 120GB SSDs (SATA III – one volume for Oracle data; the other for O/S and the adTemp directory), 24GB of DDR3 1333MHz ECC non-registered server memory, and two Intel Xeon X5650 hexacore processors.

(2) Distributed Processing Engine (“DPE”) #1Asus M4A89GTD Pro/USB3 motherboard, AMD Phenom II X6 1100t hexacore processor (watercooled, but not overclocked), 16Gb of DDR3 memory, O/S residing on an OCz Vertex 3 SSD (SATA III), and the temp directory used by the AccessData distributed processing engine residing on a separate OCz Vertex 3 Max IOPS edition SSD, and the pagefile residing on a Western Digital  Raptor 10K RPM hard drive.

(3) DPE #2 – Hewlett Packard DV6 laptop, Intel core i7 720qm processor, O/S installed on an Intel SATA II SSD, temp directory used by AccessData distributed processing service residing on a separate OCz Vertex 2 SSD (SATA II), 8GB of RAM

 

Source Evidence Configuration

In an effort to find the fastest evidence load times, I experimented with various combinations of the foregoing.  As a test image, I used a 186GB DD image (ultimately consisting of 1,052,891 evidence items), hosted on a Western Digital 4TB My Book Studio Edition II (SATA II – up to 3 Gb/sec) configured as RAID-0.  I used both KFF alert and ignore, MD5 & SHA1 hashes (but not SHA256 or “fuzzy” hashes), expand compound files, flag bad extensions, entropy test, dtSearch index, create graphics thumbnails, data carve, meta carve, registry reports, include deleted files, and explicit image detection (X-DFT & X-FST).   Using oradjuster, I tweaked the SGA_TARGET parameter to use only 18% of available physical memory during evidence processing.

 

Distributed Processing

Before continuing, I’d like to mention a few things about the Distributed Processing Engine, which are hard-learned lessons from either failing to read the user guides and appendices, or from experimentation:

(1) To get DPE working, you must have a system share as the path to the evidence in the Add Evidence dialogue box.  Without it, no distributed processing will occur.  Likewise, you need to have the Oracle working directory on a public share, the FTK-cases directory on a public share, and all systems using mirrored accounts (which Microsoft defines as “a matching user name and a matching password on two [or more] computers”).   You also need to disable any Windows firewalls or other firewalls.  Tip ►  An easy way to make certain the port on a DPE is reachable is to install PortQuery v. 2, and run the command, “PortQry -n {machineName} -p tcp -e 34097″ where “machineName” is the name of your DPE, and where 34097 is the default port (configurable in the distributed processing configuration menu). AccessData ought to include a “test connection” button in the distributed processing configuration — it would probably save their help desk a lot of e-mails and calls.

(2) And, although the v4.0 System Specification Guide discusses how to configure the adTemp directory on the localhost processing engine (which directory should be located on its own, high i/o throughput drive, because it is the interface between the processing engine and Oracle), I have found no discussion about how to optimize the DPE machines.

Tip ►  On a Windows Vista or Windows 7 machine, if you are logged on as “farkwark,” the distributed processing engine will write its files to Users/farkwark/appData/Local/Temp.   To relocate this /Temp directory to a different drive, you need to create a junction, as follows.  First, log off and log on as a different admin account user.  Next, move (not copy) the /Temp directory to the different drive (say F:).  Rename it, if you like (e.g., “FTKtemp”).   Now, from a command prompt, type:

mklink /j “Users\farkwark\appData\Local\Temp” “F:\FTKtemp”

From this point forward, the processing engine will, in fact, be writing its temporary files to the F:-drive, thereby not competing with the O/S drive for i/o.

 

Hardware Configuration Experiment No. 1: FTK & Oracle Server + DPE #1 & DPE #2

With this three-machine configuration, I rarely saw the FTK & Oracle server’s 12 cores (24, if one counts hyperthreading) get above a collective 15% of load.  DPE #2 (the HP laptop) processing load reached near 100% several times, with up to 6 of 8GB available memory in use. DPE #1 reached between 50-80% CPU utilization with extended periods of low utilization, and about 8GB (of 16GB available physical memory). Total time was 11 hours, 24 minutes.

 

Hardware Configuration Experiment No. 2: FTK & Oracle server (one box implementation), alone

With this one-box configuration, the dual xeon hexacore CPUs were pegged for extended periods of time at 99 or 100% (note, this differs from the experience of others, who have written,”We have multi cored, multi processor CPUs on our systems. What we’ve found is that typically, unless we are password cracking, that the I/O from the disks can’t keep up with resources available. Meaning our CPUs are never maxed out. So the CPUs are not the bottleneck for getting more speed“). The FTK/Oracle server used up to 20GB (of 24GB available) of physical memory (recall that SGA_TARGET was set to 18%).  Total time elapsed was 9 hours, 4 minutes, an improvement of 20.5% over using a three-machine distributed processing configuration (no, that’s not a typo).

 

Hardware Configuration Experiment No. 3: FTK & Oracle server + DPE #1

With this two-machine configuration, the FTK Server’s CPU utilization was rarely  above 40%, only occasionally reached 60%, and most usually was between 5 to 25%, and used between 8 to 12GB (of 24GB available) of physical memory.  Meanwhile, DPE #1′s CPU utilization was pegged at 99 to 100% for extended periods of time, and used up to 10GB (of 16GB available) of physical memory.  Total time elapsed was 8 hours, 33 minutes, a 25% improvement over the 3-machine distributed processing configuration, and only a 5.7% improvement over using the FTK/Oracle one-box solution.

 

Hardware Configuration Experiments Conclusion

Based on the type of hardware I am using, I found very little benefit (up to 6% processing time improvement) and, in fact, some detriment (over 20% in processing time loss) in stringing together numerous DPE workstations.  My experience is inconsistent with AccessData’s findings of processing time differences between stand-alone boxes and distributed processing clusters (see http://accessdata.com/distributed-processing).

 

Add-on Modules: Data Visualization & Explicit Image Detection

Initially, I thought the Data Visualization module did not work. No matter whether I attempted to view a directory containing several score of files, or the entire 1 million + items, it never displayed more than a handful of results (sometimes zero or one, resulting in a pie graph that was just one big green circle).   Turns out (of course) that It was my fault for failing to “select” the appropriate date range.  Had I read the manual first, I would have noticed, “Information can only be displayed for the date that you have selected.” FTK 4.0 User Guide at 200.  Apparently, when the Data Visualization tool first opens, it defaults to one day (the first day of the oldest evidence in the list) –not very inuitive.

AccessData claims that the Data Visualization add-on component “provides a graphical interface to enhance understanding and analysis of cases. It lets you view data sets in nested dashboards that quickly communicate information about the selected data profile and its relationships.”  Among other things, it purportedly provides “a complete picture of the data profile and makeup,” empowers the examiner to “Understand the file volume and counts through an interactive interface,”  and “Create a treemap of the underlying directory structure of the target machine for an understanding of relative file size and location” (similar to, but not as elegant as WinDirStat).

In summation, the tool appears to work as designed, although I haven’t done any substantive reporting off of it.  One user posted on the AccessData forum that there appears to be no way to export the graphs in to a report, but this can be easily remedied by taking a screen clipping using SnagIt, Microsoft’s OneNote, or a screen print.

Also, I have been experimenting with the EID. AccessData states, “This image detection technology not only recognizes flesh tones, but has been trained on a library of more than 30,000 images to enable auto-identification of potentially pornographic images . . . AccessData will continue to integrate more advanced image search and analysis functionality into FTK. Customers who have added the explicit ID option to their Forensic Toolkit® license and are current on their SMS will automatically receive those new capabilities as they become available.” Notwithstanding this commitment, it appears that no additional functionality has been added since its release with FTK 3.0.  I also note that the technology is unlike Microsoft’s “PhotoDNA,” which is reputed to process images in less than five milliseconds each and accurately detected target images 98 percent of the time, while reporting a false alarm one in a billion times. Comparatively, AccessData’s EID has been found to achieve 69.25% effectiveness with 35.5% false positives. Marcial-Basilio, Aguilar-Torres, Sáchez-Pérez, Toscano-Medina, Pérez-Meana, “Detection of Pornographic Images, 2 Int’l Journal of Computers 5 (2011).

My experience reveals many false positives (such as, “small_swatch_beige.png,” an image consisting of a plain beige coloured box, ranking at the very top of the list compiled by the X-ZFN algorithm, which is supposed to be the most accurate of the three algorithms), and seems to confirm that the algorithm is based on the presence of flesh tones (and nothing more, unless your system has one or more of the 30,000 images that became part of the library at the time the tool was introduced). Nevertheless, if one is short on time (and many law enforcement agencies’ examiners are), the tool does certainly help to reduce the data set that requires manual review.