Wiping & Protecting Data from SSD/Flash Drives

USB Flash DriveI received a comment from a reader of this blog (hi Ziyad!) about an very old article posted in 2008 (!) about tools to wipe files from drives. I reviewed a list of tools available on Linux (or other UNIX flavors) to safely delete files. As you probably already know, deleting a file using the standard system call is not enough from a security point of view. The blocks used by the unwanted files are just tagged as “free” and are not overwritten. The goal of such “eraser” tools is to write random data in several passes. This is a valid technique for classic hard drives but, it’s not the case for new medias like Flash drives or SSD. Those new types of storage become more and more common in laptops, netbooks and even servers now. They have multiple advantages:

  • Fast startup (no need to “spin up”)
  • Silent!
  • Low power consumption
  • Fast random access
  • No moving parts (less risk of mechanical problems)

Try yourself the following demonstration. Connect an USB flash disk to your laptop:

   # tail -f /var/log/messages
   [...] usb 2-1: new high speed USB device using ehci_hcd and address 10
   [...] usb 2-1: configuration #1 chosen from 1 choice
   [...] scsi7 : SCSI emulation for USB Mass Storage devices
   [...] scsi 7:0:0:0: Direct-Access     USB2.0   Flash Disk       2.50 PQ: 0 ANSI: 2
   [...] sd 7:0:0:0: Attached scsi generic sg2 type 0
   [...] sd 7:0:0:0: [sdb] 1024000 512-byte logical blocks: (524 MB/500 MiB)
   [...] sd 7:0:0:0: [sdb] Write Protect is off
   [...]  sdb:
   [...] sd 7:0:0:0: [sdb] Attached SCSI removable disk
   # df | grep /media
   /dev/sdb                511504     14304    497200   3% /media/001B-9622

Create a temporary file with pseudo sensitive data like a credit card number:

   # mkdir /media/001B-9622/test
   # echo "Xavier|1234-5678-90|2010-12" >/media/001B-9622/test/data.tmp

The data are available via the raw devices:

   # strings /dev/sdb | grep -i "1234-5678"

Now, safely remove the file using the wipe command:

   # wipe /media/001B-9622/test/data.tmp
   Okay to WIPE 1 regular file ? (Yes/No) yes
   Operation finished.
   1 file wiped and 0 special files ignored in 0 directories, 0 symlinks removed but not followed, 0 errors occured.

Search again on the raw device:

   # strings /dev/sdb | grep -i "1234-5678"

The sensitive information is still present on the drive! Why?

A disadvantage of the SSD technology is the limited life-time (limited number of write cycles). To avoid this problem, the manufacturers use a technique called “wear-levelling” for prolonging the life of the SSD media. Basically this is a work-around which consists of distributing erasures and re-writes across the medium. This is great to extend the life-time but this brings up more security risks!

If you delete or overwrite data, new sectors will be used and the original data will remain on the original location for a while! Based on this security considerations:

  • Encryption of data already existing on the SSD is NOT safe!
  • Wiping of files does NOT work!

To safely store files on a SSD or Flash device, you can create a TrueCrypt container before copying files! To safely remove files, reformat the whole device. If you really need a 100% safe solution, a hammer could do the job 😉

But, an alternative solution exists: The support of TRIM by Operating Systems:

In computing, a TRIM command allows an operating system to inform a solid-state drive (or “SSD”) which data blocks, such as those belonging to a deleted file or affected by a format command, are no longer considered in use and can be wiped internally.” (source: Wikipedia)

Good news, Linux already supports TRIM via the hdparm command. More information is available here. Keep this in mind if you store confidential data in SSD or Flash devices!


  1. Not too sure if this place have frequent visitors and if its the right place to post this question….

    An SSD with TRIM, will it address the security-issues brought about by wear-leveling?

    AFAIK, during a file-encryption operation, the file is encrypted and re-written back into the same sectors/blocks, no files are deleted (except for the temp files created during the encryption process). As such, if the encrypted file is written back into the same space occupied by the previously plain file, then there should be no additional fragments of the files being written around on the SSD, right?

  2. What if you try to clean a flash/ssd using:

    dd if=/dev/urandom of=/dev/sdb

    Would that wipe/overwrite all the sectors on a usb-flash memory?

    And what about the reserve blocks on SSD drives, anyway to access them aswell during a wipe (since this problem exists on mechanical drives aswell – I mean when a failing sector is “relocated” to one of the reserve sectors, the original data on the “failing” sector is still available physically on the disc).

  3. One simple technique to solve this is to use only encrypted volumes with strong keys on these devices, for instance Truecrypt. Then when you want the erase the data you simply change the key in something ridiculously long and complicated, then just quick format the drive for re-use.

    It doesn’t really matter if the data is still retrievable, because of the encryption. Btw, this is how some implement digital shredding or wiping.

Leave a Reply

Your email address will not be published. Required fields are marked *