0

If I "shred" (this is a Linux utility/command) an SSD, can the data still be recovered?

N73k
  • 111

2 Answers2

5

The answer is "maybe", but it's best to assume "yes".

When you overwrite an existing file on a solid-state drive, special drivers that handle wear leveling generally often don't actually overwrite the exact location where the old data was. This is because a solid-state drive can only be written to the same location a limited number of times before the cells that hold that location wear out. So, instead of overwriting the old location, the wear leveling driver will look to see what spots on the drive have less wear on them and will map that into the location you are overwriting. The old, overwritten data is itself remapped somewhere that isn't being used.

This is a bit of an over-simplification. This remapping doesn't always happen, and different SSD devices handle this issue differently, depending on whether the operating system is aware that it's a solid-state drive. But you can never ever assume that overwriting any single file will cause that file's data to be destroyed on any SSD, and this includes MicroSD cards, USB sticks, and other portable solid-state devices.

The best way to erase the most old "deleted" data is to fill all that drive's unused space with random data. If you fill the entire amount of unused space on the drive, then you have the best chance of overwriting everything that was previously deleted. This has two caveats though. The first is, you will cause a lot of wear on your drive. You are reducing by one the number of times that every cell on that drive can be written to. The other caveat, is that you won't necessarily remove ALL old data this way. This is because many solid-state drives, including most of the better ones, have a little bit of extra space that isn't shown to the user. This extra space is reserved to be remapped into places where cells are almost worn out. Then, when it's remapped in, the old cell is mapped out permanently, but it still has whatever was in it before. Getting at that data is difficult, but often not impossible. Many manufacturers have proprietary methods of getting into see what is remapped where, and it can be possible to get into that old data. Now, the odds of a cell being taken out of service right after it had sensitive data may be low. It all depends on how much sensitive data is on your drive. But it's not zero chance.

There are two general methods for overwriting old deleted data on the drive. You can do it non-destructively (to the filesystem and current files on the drive) by simply creating a file that grows to fill up all empty space on the filesystem. You can do it destructively by filling that drive's block device from stem to stern with random data.

Non-Destructive: In Linux you can do the non-destructive method like this:

$ dd if=/dev/urandom of=random.bin

You may need to do this as root in order to also overwrite reserved portions of the filesystem. This has the effect of exhausting all free space on the filesystem, so when you do this on the root filesystem there may be ramifications when things like syslog can't write logs any more. This generally isn't catastrophic, though, and if you quickly delete the random.bin file after then reboot, you are usually good to go. A more cautious approach is first boot from a live CD/DVD/USB, then mount your SSD filesystems and do the above in them. If you have more than one filesystem on the SSD, then you need to do this with all the filesystems before you delete the random.bin on any of them.

Destructive: This is easier and has the benefit of being the most complete method you can use shy of the physical destruction of your drive. Boot off a live CD/DVD/USB, then once you determine what the physical device is for your SSD, you use:

$ dd if=/dev/urandom of=/dev/sda bs=1M

Where /dev/sda is replaced with the device of your SSD. You will have to remake all your partitions after doing this, though. There are sometimes ramifications when you make partitions on an SSD to make sure they are aligned properly to the device's internal memory cell and block size, so look into this.

Encrypting a drive in-place and then destroying the key has been proposed as an alternative solution to erasing the drive. This is at best no better than the destructive method above, and at worst can allow recovering almost the entire contents of your drive. Possible issues are the fact that some encryption products don't by default overwrite free space with random data, or have a way of turning that off, that they don't necessarily overwrite slack space in-between existing partitions or at the end of the drive.

In short, there is no 100% reliable way to ensure sensitive data is overwritten on any SSD. The only way to ensure no sensitive data can be extracted from a solid-state drive is to physically destroy it. And by that, I mean making sure the actual silicon wafer in the middle of each memory chip is fractured. There are drive shredders that are designed to do just that. Burning at high temperature is also effective.

It must be noted that almost all this pain can be circumvented (or at least mitigated) by prevention. The use of a whole-disk-encryption system from the very beginning so that no unencrypted data is ever written to the drive is by far the best way of making sure that your data is the most secure. Even so, at the EoL of the drive, however, I would still even then recommend either physical destruction of the drive or the destructive method above.

1

All newer SSD disks contain low-level "trim" functionality. Basically, blocks specified in the low level command cause the SSD to "garbage collect" these blocks, making the deleted content inaccessible and not recoverable.

An SSD disk installed will do a trim function on deleted file space in Windows systems (probably 7 and above). I believe that this can be disabled using a registry key.

In Linux unlike Windows, you must use a special mount option called discard to exercise the "trim" functionality on SSD drives. However, this can be periodically done via the fstrim command in conjunction with cron.

If the question is how to make deleted space not recoverable, then using "trim" functionality on SSDs seems to be a start.

mdpc
  • 11,914