14

When trying to securely wipe SSDs, we have several problems:

  • SSDs wear out after a limited amount of erase cycles
  • SSDs have a controller that dynamically maps LBAs (logical block addresses used by the system to access the disk) to NVRAM cells (the actual flash memory cells) to balance the wear, which means telling the disk to overwrite the blocks that formerly stored a specific file may result in overwriting any other spare blocks.
  • SSDs have a notable percentage of reserve capacity that is used to compensate dying storage cells and reduce wearing. They are not visible to the system and might hold old data fragments.

Now what options do we have from inside Ubuntu to securely wipe SSDs?

I've heard that some newer SSDs should be able to securely wipe themselves, but how do I find out whether my SSD is capable of this and how would I trigger it?
There should also be an ATA secure erase command, how do I find out if that is supported and how would I trigger that?

Are there also ways to securely wipe only a given file or only unused space?
I guess making a backup of all partitions, securely wiping the entire disk and then restoring the backup would be possible but sounds too complicated and would take too long to be practical. Are there other alternatives? If not, what tools can I use to backup partitions without also backing up already deleted files?

Of course the standard tools like shred or wipe are not usable here for the points described above. They simply overwrite a a file (by overwriting its file system clusters which are bound to LBAs which are not constantly pointing on the same flash cells due to the wear levelling controller).

9

Currently there's no way to securely erase files on SSD without erasing the content of the whole drive or access to the firmware of the SSD.

  • It's impossible to know where the SSD may store previous copies of a logical block.

  • To make matters worse, due to journalling and copy-on-write mechanisms of the file system it may be impossible to know which logical blocks may hold a previous copy of a particular file.

The only way to prevent the leakage of deleted files to someone with direct access to the drive is to encrypt them in the first place and keep the encryption key safe from prying eyes.

Addendum:

I did some research and found out that you can sort-of erase all previously deleted files if you manage to learn all the unoccupied sectors of a file system, which is generally possible and offered by some file system tools (e. g. for the ext* family), and then discard them (e. g. with blkdiscard(8) as outlined in this answer to the linked question), which returns the blocks for garbage collection until they're used again and overwritten in the process.

This is secure against everyone who cannot access the flash cells directly, so everyone who

  • doesn't have a suitable flash cell reading device and
  • cannot talk the drive firmware into revealing the content of unassigned blocks (which would require a meaningful modification of the firmware in most cases and custom ATA commands since there's no standardised way).
| improve this answer | |
  • Would you please include the key points and a summary of the instructions from that link into your answer? – Byte Commander Jul 7 '16 at 8:43
  • I linked to an equivalent AU question. I hope that's better. – David Foerster Jul 7 '16 at 10:43
  • Would securely erasing free space on boot be a viable option? – user4493605 Oct 11 '18 at 5:26
  • 1
    @user4493605: What do you mean “viable”? It’s certainly possible. Could you please open a new question if you have a new or follow-up question? The comment section is not suitable or meant for new questions or extended discussion. You’re welcome to send me a comment with a notification to draw my attention to it. Thanks. – David Foerster Oct 11 '18 at 11:57
3

Warning: In case it's not already clear, securely erasing the drive will eliminate all data on the drive and should make it impossible to recover. You should backup all critical information.

The easiest way to determine whether your drive supports secure erase is to ask it: I've used /dev/sdX in the examples below. You'll need to carefully change it to match the device you are working with:

Sources:

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

https://superuser.com/questions/1161531/how-to-un-freeze-drive-in-linux

$ sudo hdparm -I /dev/sdX | grep -i erase

On my SSD this results in:

supported: enhanced erase
2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

If secure erase is supported by your device, triggering it is a 2 or 3 step process.

  1. If the device reports that it's frozen as indicated by output from sudo hdparm -I /dev/sdX similar to this:
not   enabled
not   locked
      frozen
not   expired: security count
supported: enhanced erase

Unfreeze it by suspending and resuming your system. I did this with the command sudo systemctl suspend moving the pointer until the system resumed.

  1. You must set a password to use secure erase in this case I'm using foobar as the password, you can use whatever non-blank password you like as it's temporary.

    sudo hdparm --user-master u --security-set-pass foobar /dev/sdX

  2. With the password set you can now use it to securely erase the drive:

sudo hdparm --user-master u --security-erase foobar /dev/sdX

If your drive supports it and you so desire you can opt to use the enhanced security erase instead with:

sudo hdparm --user-master u --security-erase-enhanced foobar /dev/sdX

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.