According to the documentation for the "diskscrb" command for wiping conventional hard drives: http://www.forensics-intl.com/diskscrb.html

"Conforms to and exceeds the Government Standard set forth in DoD 5220.22-M. Can overwrite ambient data areas 9 times. (Each pass involves 3 separate writes followed by a verify pass.) This helps eliminate the potentials for the recovery of Shadow Data."

So it's ok to wipe the HDDs at least  9 times as mentioned. But how about SSDs and USB flash drives? Do I have to wipe the data on them 9 times, or is it only needed once?
Here is what I use to regularly delete the data from my memory cards, USB flash drives, etc. (I start it in the evening, and stop in the morning, e.g.: it overwrites my USB flash drive 10 times):
loopcountdd=0;   
while [ 1 = 1 ]; 
do (( loopcountdd= $loopcountdd + 1 )); 
dd if=/dev/urandom bs=4096 | pv | dd bs=4096 of=/dev/XXX; 
echo "overwritten: $loopcountdd x"; 
done


This question was IT Security Question of the Week.
Read the Aug 3, 2011 blog entry for more details or submit your own Question of the Week.


Best stop doing that. Never overwrite an SSD/flash storage device completely in order to erase it, except as a last resort.
NVRAM has a limited amount of write cycles available. At some point, after enough writes to an NVRAM cell, it will completely stop working. For modern versions, we're in the ballpark of an estimated lifespan of 3,000 write cycles.
Furthermore, internally SSDs look nothing like traditional hard disks. SSDs have the following unique properties:

Spare area, often on the order of 8% - 20% of the total flash is set aside for wear leveling purposes. The end user cannot write to this spare area with usual tools, it is reserved for the SSD's controller. But the spare area can hold (smaller) amounts of old user data.

A "Flash Translation Layer", FTL. How your operating system 'sees' the SSD (LBA addresses) and the actual NVRAM address space layout has no correlation at all.

Very heavy writing to a consumer-grade SSD may bring the controller's garbage collection algorithm behind, and put the controller into a state of reduced performance. What happens then depends on the controller. In an extreme worst case scenario, it cannot recover performance. In a much more likely scenario it will slowly regain performance as the operating system sends "trim" commands.


Lastly, from the conclusion of the paper "Reliably Erasing Data From Flash-Based Solid State Drives": "For sanitizing entire disks, [...] software techniques work most, but not all, of the time."
So when you're completely overwriting flash storage, you may be performing an effective secure wipe -- but, you may also be missing some bits. And you're certainly consuming quite much of the drive's expected life span. This isn't a good solution.
So, what should we be doing?

The 'best' modern drives support a vendor-specific secure erase functionality. Examples of this are Intel's new 320 series, and some SandForce 22xx based drives, and many SSDs which are advertised as having "Full Disk Encryption" or "Self Encrypting Drive". The method is generally something along the lines of:


The SSD controller contains a full hardware crypto engine, for example using AES 128.
Upon first initialization, the controller generates a random AES key, and stores this in a private location in NVRAM.
All data ever written to the drive is encrypted with the above AES key.
If/when an end user performs a secure wipe, the drive discards the AES key, generates a new one, and overwrites the old AES key position in the NVRAM. Assuming the old AES key cannot be recovered this effectively renders the old data unrecoverable.


Some drives don't have the above, but do support the ATA Secure Erase commands. This is were it gets more tricky -- essentially we're relying on the drive manufacturer to implement a 'strong' secure erase. But it's a black box, we don't know what they're actually doing. If you need high security, then you should not rely on this, or at least you should read the tech docs and/or contact the drive manufacturer to verify how secure their method is. A fair guess as to what they're doing / ought to be doing is that:


While the drive isn't using a full cryptographic cipher such as AES, it is still using extensive data compression algorithms & checksumming & RAID-like striping of data across multiple banks of NVRAM. (All modern high-performance SSDs use variants of these techniques.) This obfuscates the user data on the drive.
Upon receiving an ATA Secure Erase command, the drive erases its "Flash Translation Layer" table, and other internal data structures, and marks all NVRAM as freed.

My personal recommendations:

If you just need an insecure wipe of an SSD, then use the manufacturer's end user tools, or use the ATA Secure Erase command via for example hdparm on Linux.

If you need secure wipe then either:



Only use drives which explicitly advertise secure wipe via strong (AES) encryption, and run the manufacturers secure wipe. and/or:
Ensure that all data you write to the drive is encrypted before hitting the drive. Typically via software full disk encryption such as PGP Whole Disk Encryption, TrueCrypt, Microsoft BitLocker, BitLocker To Go, OSX 10.7 FileVault or LUKS. or:
Physically destroy the drive.

