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.
Wasn't this... (Score:5, Interesting)
...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).
Re:Well... (Score:5, Interesting)
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.
Re:Why can't they make up their minds (Score:5, Interesting)
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.
Re:trim/discard (Score:2, Interesting)
The solution is simple: Don't power up SSDs. Desolder the chips, read them with your own controller, reconstruct the data. Of course the shit hits the fan when the controller applies encryption and stores the key in the controller itself where it cannot be read from the outside.
TRIM (Score:5, Interesting)
It used to be the drive remapping meant that if you deleted something (or even overwrote it), there was no guarantee it would be gone - SSD controllers do wear leveling to avoid having part of the drive get used excessively. Forensic analysts could go pull the raw data from the NAND flash.
The problem was that the wear leveling algorithms need a "free block" pool to work well. Drives that have been used heavily deplete the free block pool, and the drive slows down. For a long time, SSDs would have no knowledge of whether a file had been deleted or not.
The ATA TRIM command was added for just this purpose - with TRIM, when the OS deletes a file that references a block, it can tell the SSD controller that those blocks are free. The SSD controller will then begin erasing those blocks in its free time. (SSDs can be written one block at a time, but must be erased one page at a time. A page consists of multiple blocks. Oh, and I may have page/block swapped here.) So you get a lot of performance improvement by having a bunch of pre-erased pages - these can just have individual blocks written without a read/erase/modify/write on a whole page.
Pre-TRIM, SSDs were probably great for forensic analysts. Post-TRIM, SSDs are not. Oh, and I think the latest ATA standard added a "sanitize" command to make life easier for information assurance types, for whom SSDs have always been a pain.
Re:Good. (Score:4, Interesting)
SSDs do wear-leveling. If one logical block is busy, it will migrate from physical block to physical block over time to balance activity counts. The physical blocks left behind have data that the OS cannot purge by any means. The drive's firmware is certainly aware of these blocks, and will eventually wipe them for re-use (though given this is a wear-leveling scheme, reclamition isn't necessarily that urgent).
This is all separate from file system activity: in addition to the above, the firmware purges TRIMmed blocks, and presumably does so in preference to blocks rotated out do to wear-leveling, so a block that did get TRIMmed would be agressively purged.
Re:Why can't they make up their minds (Score:4, Interesting)
Trust me, dd can really make a mess of things, if by intention or mistake.
I was cloning one drive (A) to a larger one (B). It needed to preserve the partition table, MBR, etc.
dd of=/dev/sda if=/dev/sdb bs=1024
About 10 seconds after I hit enter, I saw the mistake, and aborted it. Ya, I dd'd an empty drive over the populated one. How much harm could that possibly do, right? :)
I've done plenty of drive recoveries, with about an 80% success rate. The only ones I can't do are drives that don't spin. I don't have the facilities to transfer the platters.
Two weeks and several recovery attempts, I had recovered about 25% of what I wanted. The partition table, and the MFT were destroyed, and files were on four partitions with two different filesystems (NTFS and ext3). That was in 10 seconds. If you were to say" dd if=/dev/random of=/dev/sda bs=1024", it's rather unlikely even the best would find anything.
From what I understand, the best chance at recovering data from an overwritten media is to look at sectors marked as bad. They are automatically skipped, so they don't get overwritten by anything. Who knows what will be in them though. Most likely on most users machines, it will be pieces of the browser cache, or Windows Update files.
That's not to say if some agency named "No Such Agency", were really bent on finding out what I had on there, they couldn't recover something. Many agencies can't go beyond files that currently exist, or are in the "Recycle Bin". Some go as far as undeleting from an otherwise functional filesystem. Is it worth weeks and thousands of dollars for whatever organization to recover what you have hiding on your desktop? Probably not. If you have secrets, don't hide them on your PC at home, even if you are protected by a nice wood front door with fancy security locks. One brick through the window, and a fast getaway, will defeat any door lock and alarm system. If you kept all of your important information on some random colocated server in another country, AND you have a second person with access to clear your data, it would be untouchable by most agencies. Say I had a server colocated in China, with the normal protections (encrypted virtual filesystem, etc, etc.), and only used my desktop to manipulate them through a terminal session (VNC, SSH, etc) the most that could be found is that I connected to a server in an untouchable place, and by the time they managed to get to it, my 2nd party could have removed it.
Re:Good. (Score:5, Interesting)
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.
Re:trim/discard (Score:4, Interesting)
2 - Defragging: similarly, if you're moving data around in dead space without safely duplicating it or having a filename pointing to the blocks in use at any given time, you're not being careful. Also, which defraggers have random 3-minute gaps in operation that would even allow GC to kick in?
I think it is time to start bringing the discussion to a close, as it appears that we do share at least some common ground.
I will comment only on this one question. Your implication that the 3-minute rule somehow makes the GC "safe" is missing my point entirely. Yes, in practice there are checks and balances such as you describe, that make the GC unlikely to screw up. But, in my view, "unlikely" is not good enough. I want, and need, perfect (logical) block storage and retrieval. This should and must be the design goal. Of course, this goal is impossible to achieve in practice. For example, if the firmware (such as older, pre-SSD firmware) is designed with the goal of providing logical block storage, but fails in this task because of some honest bug, then I can understand that. At least, in this case, the programming code was written unambiguously with the correct goal (and no other directly conflicting goals) in mind, even if this goal was not achieved in practice due to an unintentional bug.
However, when a manufacturer deliberately designs firmware with the goal of deleting logical sectors, no matter how well-intentioned or well-implemented, this design goal (by definition) must come into conflict with the original, core goal of reliable (logical) data retrieval. I do not care what happens in the underlying physical layer, but I do care very greatly about data accuracy at the logical layer. The existence of certain checks and balances to prevent data loss is better than no checks and balances, but it is not better than the REAL alternative, namely, firmware that stores and retrieves logical blocks correctly, and is designed for this and only this purpose, without any other directly contradictory design goals.
No one, not even rocket scientists, has ever succeeded in writing bug-free software. But one should make an effort to minimize the number of opportunities for data loss bugs to arise. Firmware-based logical-sector garbage collection fundamentally and irreconcilably contradicts every reliability design principle known to man. That is why I consider the idea to be so abhorrent.