You're welcome, it's great to hear people's thoughts about our work and to have the opportunity to get the message out about this result to a wider audience.

Graeme.

Mirror'd it here for you Andy.

http://graemebell.net/downloads/JDFSL-V5N3-Bell.pdf

Graeme.

Thanks for your comments.

"That image in raw data will show that the drive would have been garbage collecting as the image was being taken."

Keep in mind the established court procedure to verify if an investigator's image (and finding) is valid, would be to e.g. run an MD5 over the original disk with a write blocker attached in front of defense and prosecution. That will show 'no match', and by precedent the investigator's copy and findings (not the original) will become devalued, practically to zero.

Also, how could a forensic investigator show a court that his image 'really' was the original version?

There's no authoritative copy representing the data at time of capture to refer to any more, if the original was being modified as he took the copy.

Graeme.

If you take a look at: http://www.jdfsl.org/subscriptions/JDFSL-V5N3-Bell.pdf , you'll see the drive model we used was the Corsair P64 (see page 16).

There's also support for GC on the OCZ vertex 2 drives, I think. However, some bad news and good news for you:

The bad news is, the firmware GC implementation we looked at only supported GC on NTFS partitions.

The good news is, you can use NTFS with macos if you like (e.g. through FUSE), or you can wait for MacOS Lion, which is about to be released, and which is rumoured to support TRIM directly. Shouldn't be long!

Graeme.

Hello Noughmad.

I don't see anything unusual about being interested in having a discussion about my results with other people - in fact, I'd say that's pretty much the whole idea of scientific publication.

Unfortunately, the way the comment moderation system is set up on this site makes it very hard to talk back and forth without help - new / temporary accounts are by default set to be almost invisible to casual readers. Given the choice between looking good from your perspective, and being able to easily engage in two-way discussion with interested slashdotters about SSDs and forensics, I'll take the latter :-)

Graeme.

Inaccurate. These drives are oblivious to the file-system

Hey there. Unfortunately, what you've written isn't correct, and I encourage you to read into modern SSD garbage collection. These drives really do open up the filesystem by themselves, and look for deleted files and purge them, without being asked to do so by the OS. Otherwise, can you explain how file deletion using a non-TRIM OS, followed by a drive being connected to a non-TRIM OS with a write-blocker, would result in data being purged? (we proved this experimentally, and you can reproduce it in your own home using the supplied software and experimental parameters).

But you are wrong that the SSD is doing the purging outside of OS intervention.. the OS must specifically mark pages for purging.

The GC on the drive in question is specifically designed to provide performance improvement for *OS that do not have TRIM*. If you don't believe me, look up the drive model in the paper and google it for forum discussions of its behaviour (or buy one for yourself, and watch it happen in realtime using the probe program! It's freaky to see a drive rapidly purge it's supposedly recoverable data when connected to a non-TRIM OS)

Graeme.

A few drives offer it, with varying names and degrees of marketing fanfare, but there is little documentation as to the precise workings of the GC features. In the paper PDF you'll see the drive make/firmware for the drive we used in these experiments. You can buy that one if you like :-)

Graeme.

"...a foregone conclusion ever since ATA Secure Erase and TRIM were introduced?"

Yes, TRIM is eventually going to change the game in the sense that data will (probably) be expunged ASAP by the drive when you delete them (as you observe though, it is a request to the drive, not an instruction, and consequences of issuing a TRIM are unknown). But it could be a decade before courts will stop seeing the problem mentioned in this paper. I think the problem will peak in coming years and decline e.g. 4-5 years out as people finally give up on XP/2003, non-TRIM linux implementations of FAT32/NTFS, older Mac OS's, etc.

TRIM only works when you have a firmware and OS that support them. Given the number of people I know using XP (and below) and MacOS Snow Leopard (and below), there's a lot of computers out there who won't be sending ATA TRIM commands to their disk. Yet SSD GC is becoming more common and more aggressive in the meantime...

I would say that court practice and legal precedent is slow to update as far as technology is concerned, and SSD GC has come out of the blue for them, and is a currently a fast-moving technology that works with most non-TRIM OS's out there, and wrecks court expectations and practices that have worked for about 25 years.

Graeme.

"This property of modern SSDs is neither positive nor negative by itself. It's a property you'd be thankful for if you were organizing protests in Iran and stored contacts on an SSD. You'd curse it if it were exploited to destroy incriminating photos by someone who'd stalked you or a loved one."

Exactly right, Jonner.

Graeme.

Hello, I'm one of the authors of the paper. To explain the apparent paradox in rough terms:

Drive data was traditionally purged manually, by having the computer tell the drive to write something else over the top of the old data. In the absence of such an overwrite, magnetically stored data persists. However, if you try that trick on an SSD, it may not work. The logical address you try to overwrite may be remapped on the fly, so that your 'overwrite' goes to some other physical cell rather than the one which stored the data. From a logical viewpoint, it looks like the overwrite worked - you can't access the data any more through your computer's OS. But from the drives point of view, the data is still there, lurking in some physical cell that is presently out of use as far as the logical sector list is concerned. A cunning firmware or a hacker with a soldering iron might still get at it.

However, separately to this, modern SSD drives use tricks to try and automatically improve their performance, and one of these tricks is to pre-empetively wipe data cells that contain data no longer referenced by the filesystem. Here, the drive is actively attempting to permanently purge everything it can from the drive, all of it's own accord, in the interests of accelerating future writes by having a pool of completely unused cells available.

Summary:

- If you're a computer telling a drive to zero over some data, the drive may lie to you a bit, and not bother to zero it.

- If you're a drive, you do whatever the heck you like, and you see the physical layer directly (unlike the computer). That means the drive can open up the NTFS metadata, looking for data cells which could be preemptively reset, and nuking that data out of existence (when it might traditionally have been recoverable to an expert).

In summary. If your drive wants to nuke something, (and we've shown, they really DO want to nuke everything they can at a few minutes notice), it gets nuked. If your PC wants to nuke something, it may or may not get nuked by attempting an overwrite.

Finally, separate to this is TRIM, which is a hybrid of the two situations - an ATA command by which the OS can signal to the drive that it would like the corresponding physical cell for a particular logical sector address to be nuked, thank you very much.

Hope that clears things up.

Graeme.

- Yes, that's pretty much what they're doing, all under their own control without the PC asking them to. But they are not so much zero-ing out the data, as resetting the cell to prepare it for being written to in future more quickly. Not all drives do it, but increasingly it's built in since the technology is already written now, and people running non-TRIM OS's can benefit from it a great deal.

- Re: zeroing. Oddly enough, I seem to recall that cells are actually reset to all 1s at the physical level...

Graeme.

Hello there, thanks for your comment. Just a couple of quick points:

- SSD garbage collection doesn't destroy data indiscriminately, it destroys data that the user has manually chosen not to retain. In many ways, this is not substantially different to a user choosing to turn off their computer and losing all the data in RAM chips which they have manually chosen not to save permanently. Should we ban RAM as well, along with any device which loses non-archived data in a manner which can't be recovered from?

- Keep in mind the evidence that is destroyed can be used to prove innocence as much as guilt. It's not actually a net loss as far as courts are concerned.

Graeme.

I've spent the last hour writing replies for questions/comments on the thread using this throwaway account: could someone with uber-powers please mod them up a bit?

Thanks very much in advance, and thanks also to everyone making suggestions/comments about the article. :-)

Graeme.

You've hit the nail on the head.

But, to be fair, consider the amount of digital evidence in the world today vs. 20 years ago. Training up court-approved forensics officers to dismantle drives and their firmware in a manner which doesn't wreck the data, is a heck of a lot harder to do than teaching them to run 'dd' with a write-blocker attached.

Graeme.

-----

Hey there

Yep, it's the answer that immediately springs to mind when you approach the problem as a techie, and we touched on in the paper (see point 16, page 13).

Keep in mind though that this is extremely non-trivial - e.g. not many court officers will know how to do it - and that a court may have real trouble with a forensics guy telling them that for 'this particular case', they need to not use the standard procedure to preserve the data unmodified, but instead to rip open the disk and muck about with how it processes data.

Courts have accepted practices that are used worldwide; what you propose is not accepted practice; therefore courts will have a problem, at least in the short term.

Also, given the number of variations of controllers and firmware out there too, I'm sure you'll agree there's tremendous potential for a court forensics officer to get it wrong and accidentally nuke the drive data. e.g. how do you find out which firmware was in use, without powering on the drive (which activates the GC)...

Graeme.

p.s. Also keep in mind that data is stored on the chips in a highly non-linear manner; reassembling the logical image may not be easy, since you need to work out how the flash translation layer was being represented. This is getting wildly beyond what a typical court forensics officer is usually trained to do, namely, rip an image of the drive with a write-blocker attached and scan it for jpegs/whatever.