SSDs Cause Crisis For Digital Forensics 491
rifles only writes "Firmware built into many solid state drives (SSDs) to improve their storage efficiency could be making forensic analysis at a later date by police forces and intelligence agencies almost impossible to carry out to legally safe standards, Australian researchers have discovered. They found that SSDs start wiping themselves within minutes after a quick format (or a file delete or full format) and can even do so when disconnected from a PC and rigged up to a hardware blocker." So either SSDs are really hard to erase, or really hard to recover. I'm so confused.
Solution is simple, but not easy (Score:2, Informative)
You need to disassemble the drive and read the memory chips independently of the controller. I believe I read this is how one of the major drive recovery companies is handling SSDs.
Both hard and easy are true (Score:5, Informative)
The drives have internal overprovisioning and perform internal garbage collection. This means that marked for deletion data has an unknown lifetime and may disappear at any point without interaction from a controller.
The hard to erase bit means that you really can't be sure something is totally erased without a full specific erase command to all flash blocks. Without that a page marked unused but not erased may be nestled in with a bunch of valid pages. As all pages in a block are erased together that marked unused page can hang around for a wile.
On the other side the firmware does garbage collection it actively looks for blocks with many erased pages and then tries to consolidate things so it can create more free blocks. This means if the drive is powered but not connected to a host machine it can still be doing data moves for consilidation and erasing marked for deletion pages.
There are thresholds for the garbage collection so it won't overwork and try for 100% consolidation. Thus you get both the presence of some really sticky stale marked unused pages and some active erasing of others.
Re:Huh? (Score:5, Informative)
There is an ATA command called "TRIM [wikipedia.org]". If a device supports it, the OS can tell it that a group of sectors is no longer needed, and should be wiped.
Re:And the downside here is... (Score:2, Informative)
When Mindy the undergrad accidentally deletes her term paper and would be really REALLY grateful for a super smart and kinda cute geek to go in and recover the file with Backtrack...
OH NOES, what will I ever do without being told "thank you" and about what a nice guy I am.
Yeah it never goes any further than that outside of geek fantasies.
Not even in pornos. <-- business opportunity
Re:trim/discard (Score:5, Informative)
> Deleting a file should tell the OS that I don't need that data. That's what deleting is.
It does, and that is, in fact, what it is. So Windows unlinks the file from the directory and removes the blocks from the in-use map.
The drive, however, doesn't know any of this. It updates the requested sectors representing the directory and volume info, and that's about it. It has no idea that blocks somewhere else on the drive are no longer needed, so it will dutifully copy and maintain that data while rewriting blocks.
The idea of the trim command is that it tells the drive that the data is deleted so the drive doesn't have to worry about maintaining it. This was never needed in old drives because the data was basically ignored after being written. In SSDs, the data needs to be continuously copied around to facilitate the erasing (which wipes several thousand blocks at once).
Re:trim/discard (Score:5, Informative)
At a guess this is caused by mounting with the discard option, or trim as its called in Windows. It tells the drive you don't need the data stored where a deleted file used to be.
Maybe it's still there if you look with a microscope but who really does that?
Hello there, I'm one of the authors of the paper (Graeme).
This finding isn't related to TRIM in any way, though TRIM poses another nightmare for forensic investigators and may make the idea of examining deleted data/metadata redundant in a few years.
What's happening here is that the drive itself has some code, a garbage collector, that reads the NTFS filesystem metadata and wipes any cells it thinks aren't needed any more, so that the next set of writes over those cells can take place more quickly.
Normally this GC has seemed to take a while to kick in (various benchmarking sites suggest e.g. 30-60 minutes and unpredictable behaviour, e.g. not always kicking in when expected); here, we found that after a quick format has taken place, it reliably can be seen to kick in within minutes and also purges the drive within minutes. This is just one example of a case when the GC can kick in, of course.
Current court-accepted forensics practice is to stick a write blocker between the drive and computer, under the assumption that the drive only modifies data when a PC tells it to: but that doesn't help you when the drive itself nukes all it's data cells within minutes of being powered on.
I can imagine a situation where someone connects up the drive to power, (and possibly a write blocker), but not to the PC and makes a cup of coffee for a few minutes - by the time they connect it up for data transfer, it's too late, and they wouldn't even realise it had happened - the drive doesn't exactly make any whirrs or clicks as it wipes itself.
Alternatively, the circumstances we found: in less than the time that would be taken to read an entire image off the disk for forensic study, the GC is racing ahead of you and purging the disk! Yikes. So you can imagine... a forensic investigator takes an image, examines it, presents it to the court, and when the court verifies the original disk that the copy was taken from, nothing is there any more, and the forensic investigator seems to be making it all up....
So this feature has the potential to make it look like the police or forensic investigator themselves tampered with the original disk, as well as potentially destroying evidence that could help establish guilt or help establish innocence. We've put a number of 'interesting legal grey areas' at the back of the paper that we hammered out with reviewers, which are worth being aware of.
Graeme.
Re:Good. (Score:4, Informative)
Re:Good. (Score:5, Informative)
The drive's firmware is responsible for remapping blocks, and so the OS can't really control what happens whenever the OS tries to permanently delete things by asking the drive nicely to do so. Consequently, if the drive decides it's best to remap the logical block silently while not deleting the cell contents, then the OS doesn't realise the data is still there. That's what the other SSD study noted.
On the other hand, in this situation, the thing doing the purging is the drive's firmware itself, not the OS, and the firmware knows for sure where the data is in the cells, and furthermore it's on a mission - to purge cells that it knows the filesystem is no longer using for data.
The purging that is being done here, is taking place with the specific intention of getting cells freshened up and ready to be written to in future without delay. Consequently we can reasonably expect that the drive firmware really *wants* to nuke cells that contain real data that is no longer needed according to the filesystem metadata since that's the only way to boost performance, and that's the GC's job.
If you want to check for yourself, try carrying out reads at the sector level yourself after running the experiment with the experimental setup described in the paper. You won't get much.
I guess what I'm saying is that both studies are right despite the apparent contradiction, since they're dealing with completely different circumstances and motivations for 'purging' - OS or drive GC controlled.
Graeme.
p.s. Does anyone know of a postdoc position in AI, robotics, or bioinformatics in Grenoble, France? I'm currently looking for a new job.
Re:trim/discard (Score:5, Informative)
"The drive, however, doesn't know any of this. It updates the requested sectors representing the directory and volume info, and that's about it. It has no idea that blocks somewhere else on the drive are no longer needed, so it will dutifully copy and maintain that data while rewriting blocks."
Actually, this is no longer correct. SSDs (such as the one in this study) are quite capable of examining the filesystem stored on the drive, independently, and the concept of 'dutifully' and ignorantly maintaining deleted data goes out of the window as a result.
The main point of the paper is not that this 'analyse-and-purge' drive GC behaviour happens (which is well known among SSD enthusiasts), but that it fouls up long-accepted court and forensics assumptions about what computer drives are. It can result in loss of evidence (of guilt or innocence) very easily in court cases in a manner which might be incorrectly attributed to malicious human intention.
Graeme.
Re:trim/discard (Score:5, Informative)
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.
Re:trim/discard (Score:4, Informative)
Re:This is great news (Score:5, Informative)
Not likely in this situation - here, the GC isn't killing the data for the hell of it, it's killing it because it needs to reset the cell preemptively in order to maintain drive performance at a high level. If you preserve the data in the manner of an old HDD, you nuke performance by forcing the controller to do a reset before future writes.
Graeme.
Re:TRIM (Score:3, Informative)
Re:Solution is simple, but not easy (Score:3, Informative)
-----
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.
Re:Good. (Score:4, Informative)
These drives are oblivious to the file-system, which is why there needs to be a TRIM command which allows the OS to say "hey, I don't care about that page (4 KB) any longer."
Some SSDs actually do understand a few filesystem formats (maybe just NTFS?), and used this to GC unused blocks before TRIM was implemented.
"So either SSDs are really hard to erase, or..." (Score:5, Informative)
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.
Re:Good. (Score:4, Informative)
If you take a look at: http://www.jdfsl.org/subscriptions/JDFSL-V5N3-Bell.pdf [jdfsl.org] , 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.
Re:Good. (Score:4, Informative)
"To clarify - is this deletion occurring because the drive analyzed the filesystem metadata and decided it would be a good idea to zero some sectors, or is it an asynchronous response to a fast TRIM command applied to an extent covering the whole drive?"
It's not TRIM. We used a non-TRIM OS and a write blocker for this reason. The manufacturer has mentioned a garbage collector that works with NTFS, and the only way it could work is by zero-ing areas of the SSD using information gleaned from the metadata. Hope this clarifies the situation for you! :-)
Graeme.
Re:trim/discard (Score:4, Informative)
"How would it do this without maintaining firmware for all possible types of file systems?"
It wouldn't. But, how many different filesystems are in realworld use on 95%+ of systems? HFS+, ext2/3, NTFS, FAT32?
I can imagine that it does this for simple FAT16 or FAT32, but I doubt they deal with NTFS or EXT3 or HFS.
It does work on NTFS, and if you set up an experimental rig similar to the one we describe at the back of the paper (page 16), hopefully you can satisfy your doubts :-)