Slashdot Mirror
SSDs Cause Crisis For Digital Forensics
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.
Deleted, should mean deleted.
Why the confusion, dear editor? This should be well understood.
If you want to recover, you can't. If you want to erase, you can't. It's Murphy's Law of Data Storage.
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.
...a foregone conclusion ever since ATA Secure Erase and TRIM were introduced?
Secure Erase basically tells the SSD that all of its cells are now blank (AFAIK implementations actually zero the drive as well but I'm happy to be corrected on that); therefore as soon as anything is written to the disc, it will be written here, there and everywhere. It took about 30s to run on my first vertex and I couldn't find any trace of
TRIM support in the ATA spec, along with kernel/filesystem support, tells the disc that when file A is deleted, cells X, Y, and ABQ are now officially "empty" and that if the controller feels like it, it can zero them out, shunt other data in there, or have a mardi gras for all it cares. The same happens when a drive is formatted; OS tells drive controller "I've just formatted you" and for the sake of preserving performance the controller goes "Brilliant! I can chuck out all this shit I've been saddled with."
As soon as hard drives start intelligently erasing/shuffling bits of themselves about so that cells are utilised to their utmost efficiency this was bound to happen. Unlike spinning platters where bad blocks were reallocated only if a) the hard disc knew about it and b) the data could actually be read/recovered, it becomes terribly obvious that data on SSD's is going to be read and written and deleted completely and utterly all over the place, without sequential series of sector found in slackspace like you would on a magnetic drive.
Magnetic drives have no performance penalties for not actually erasing the data, so if you work your way around that double negative you'll see that one of the staples of digital forensics (e.g. recovering files from slack) is a by-product of people trying to make magnetic platters as fast as possible by not actually erasing stuff, because as long as the controller knows that sector is blank then it'll just be overwritten as needed. Technology has now changed sufficiently that the performance gains from new solid state tech are helped by a drive controller that erases stuff as soon as possible, since writing over an occupied cell is slower than writing over a blank one.
I'm sure there'll be new methods to mitigate the change in tech, we're just somewhat on the cusp of a completely new tech. They'll probably come to an agreement that TRIM doesn't actually delete stuff until the amount of free space in the cells reaches a certain threshold or something like that.
Disclaimer: I'm not a digital forensic scientist, but am friends with one and we discussed this problem over some exquisite cocktails a few months back. And I don't think TRIM instructions follow the exact specifications I laid out above (e.g. using Brilliant! as an ACK).
Moderation Total: -1 Troll, +3 Goat
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.
It's a good joke, but with a grain of truth in it. If you're concerned, you can buy the drive we used, flash it to the firmware we used, (optionally) buy a write blocker if you like, and run the programs I placed at the back of the paper and see what happens. We carefully documented as many of the experimental setup parameters as we could so it should be possible to reproduce the results exactly.
Skepticism is a good thing - so I hope you'll reproduce the experiment at home and tell the world afterwards if you still think we're running PsyOps for the forensics community :-)
Graeme. p.s. I'm currently looking for a postdoctoral/research engineer/research scientist position in Grenoble.
You wrote: "So if you're in your secret lab and you hear that the evil enemy is an hour away, you just type "rm /*" and wander off to escape. By the time they get there all your data will be completely wiped. On the other hand if they are breaking down the door to your secret lab and you have only seconds left you can't type "shred /home/joeari/secretfile" and expect it to be perma-deleted like you could with a magnetic drive."
Actually, we found something even more interesting when we prepared this paper.
An evil criminal could run a quick format (about 8 seconds effort) if police were at the door, or they could set up a dead man switch to do the same. When the investigator powers up the drive, the drive's internal GC runs quickly (we couldn't get any formal documentation about why this is - presumably it begins so quickly since the filesystem metadata is nice and simple to process) and so after about 3 minutes it begins wiping itself.
Just a few minutes later it has finished, and data and old filesystem metadata are gone (at least, gone as far as logical access to drive sectors is concerned).
I'd encourage anyone who finds the result interesting to take a glance at the original paper, it's written to be accessible to people outside the traditional drive forensics community and there are some fun, free script tools you can use to monitor drive GC behaviour in near-realtime.
Graeme.
Plaintiff's Attorney: "Sir, what are the chances of the drive automatically generating the exact sequence of bits required to form this email?"
Expert Witness: "Billions to one, certainly."
Defendant's Attorney: "And how many times will that this 2KB email fit on the drive?"
Expert Witness: "Well, it's a 2TB drive, so... about a billion, give or take."
Defendant's Attorney: "So, assuming the data on the drive is random, then it's safe to say there are at least two billion opportunities on this drive to produce this email?"
Expert Witness: "That's not what I meant..."
Defendant's Attorney: "Yes or no?"
Expert Witness: "Well, yes, but..."
Defendant's Attorney: "No further questions"
Learn about Photography Basics.
"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.
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.
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.