28

I would like to know if there is a way to securely erase USB flash drives without a chance to recover data from it once it has been erased. I know, that programms like DBAN can be used to securely erase HDDs, but as they work different from flash based drives, I am not sure if I can use DBAN to securely erase my USB drives.

If DBAN cannot be used, how do I erase USB flash drives?

I know that SSDs have to be erased using programs that reset the data cells and are often available from the manufacturer, but I do not know if this is also the case for USB flash drives.

Community
  • 1
user295031
  • 281
  • 1
  • 3
  • 3
  • You can use data shredders for usbs also.. – Maximin Jul 06 '14 at 13:43
  • 2
    Or a hammer, or a camp fire. The only truly safe way to erase a medium that performs wear-levelling and the like that you have no direct control over (even when you _think_ you are overwriting everything) and cannot verify. – Damon Jul 07 '14 at 13:34
  • http://privazer.com/ Try this, it's a very capable software – BRaj Oct 11 '16 at 15:36
  • 1
    I've used something called active kill disk on USB drives with no problems so far. – Michael Miller Oct 11 '16 at 03:12

7 Answers7

14

UPDATE: Upon looking back it looks like using random data is not really necessary as a successful platter-level 'previous state' attack on a zeroed drive has yet to be proven possible in a real-world attack.

I've left the references below for posterity and because it does technically work fine if you're using random data, but given that just using 0s is much faster, that's probably the more reasonable option.

Flash storage, particularly SSDs, require a block/cell be wiped before more data can be written. As a result, writing would be slow if additional technology wasn't implemented.

Instead, your drive actually has 10-20% more storage than the listed capacity and an onboard memory controller will dynamically map empty cells and, during low load, wipe unmapped ones. This creates the security issue that you've encountered.

Without a tool that can leverage the memory controller your OS has no way of addressing every single cell at any given time. Many manufacturers are now providing tools that will allow you to manage the drive and securely wipe it but should your drive not have such a tool there are few perfect workarounds.

Aside from reverse-engineering a tool to manage the memory controller the best method I know of is to do many successive writes.

dd if=/dev/urandom of=/dev/devicename

Filling the drive with random data and then doing so again and again will cause the drive to constantly remap the cells and eventually you'll overwrite enough of them to be reasonably secure. The more successive overwrites the higher the chances that you will have written to every cell.

NOTE: Technically, these successive overwrites should also be done with a traditional HDD, but for a totally different reason. High accuracy equipment may be able to read previous magnetic states directly from the platter to recover data. This is why it's important not to overwrite with 0s or 1s, as it'll leave a easy to determine the previous state of the bits.

For an easier fix, throw the drive through a physical shredder. Obviously not a solution if you plan on reselling or reusing the drive but generally one of the most secure methods.

Jeff Alyanak
  • 281
  • 1
  • 5
  • 4
    You might not want to use urandom because it is so slow. Instead, either use openssl seeded with a key from /dev/urandom, feed from /dev/zero to provide a stream of high-speed pseudorandom data, or use cryptsetup to create /dev/mapper/devicename_crypt and write zeros directly to there. That will wipe it at rates of hundreds of MiB/s, rather than around 5 MiB/s. – forest Apr 08 '16 at 08:28
  • With GNU utilities there is also 'shred', so you could issue something like 'shred -vz /dev/devicename' which will by default overwrite the device three times with random bytes and then zero it out. – Mike Simpson May 14 '17 at 17:57
  • 3
    Actually, it seems like random data might actually be unnecessary as there have been no real good platter-level attacks on properly zeroed drive platters. – Jeff Alyanak May 27 '17 at 03:30
  • @forest Actually, I can get something like 70 MiB/s on a mid-end laptop by changing `dd`'s block size. 64 kb will make it way faster. – Hey Jun 20 '17 at 21:33
  • @Arno You must have been using one of the more modern 4.x kernels, which totally reworked the random driver in Linux to use a ChaCha20-based stream cipher instead of slow SHA-1 mixing. That driver rework did not exist at the time of my original comment. – forest Nov 03 '18 at 12:35
7

Without knowing your particular use case I'll supply an alternative answer that you might find useful, and it's one I use myself.

Encrypt the data stored on the device.

  1. Use a device such as the LOKIT (http://www.lok-it.net/) which has built in encryption.
  2. Create a TC (TrueCrypt) container and put all data in this. Once you're done, change the password to a long random string and then delete the container.

I realize this doesn't answer your immediate question, but perhaps it'll give you some ideas for the future.

Christoffer
  • 1,030
  • 1
  • 6
  • 14
  • 1
    I wouldn't use TrueCrypt anymore the website says it has some unfixed security issues. – that guy Jul 06 '14 at 17:28
  • Source: https://opencryptoaudit.org/reports/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Security_Assessment.pdf – Christoffer Jul 06 '14 at 18:53
  • 6
    Encrypting would make sense if it is being done before data is written to it. I want to erase drives that already contain data/that have been used a long time. – user295031 Jul 06 '14 at 22:08
2

Encrypt a large picture of noise such that the file size occupies most of the drive. Do the same for a medium sized picture and then a small picture. Copy the large picture to the drive and if you have any room left over copy the smaller pictures to it. Avoid copying the same file to the drive more than once. Repeat the process with new pictures of noise. Repeat again.
You are now pretty darn safe. At this point, I would expect ONLY the NSA would be able to decrypt the portion of the drive that was repeatedly written to.

If the issue is a magnetic hard drive then the answer is a bit different. For a magnetic hard drive, use a program that is designed to perform a high-level shredding operation - I think it involves 11(?) wipes.
If you want to get ridiculous, repeat the process two more times, once at an elevated temperature (say 90F ambient) and then again with the computer at a very low temperature (e.g., 50F). That will help shift the read-write head relative to the platen by a few billionths of an inch so that the edge boundaries are scrubbed a smidgen more than they would have been otherwise. This would be pretty effective as long as the scrubber ignores the parts of the HD that were labeled as "BAD" and scrubs the BAD along with the good sectors. Cool?

guest
  • 21
  • 1
  • " I think it involves 11(?) wipes" With modern, high storage density HDDs, a single overwrite is enough.[(source)](http://www.howtogeek.com/115573/htg-explains-why-you-only-have-to-wipe-a-disk-once-to-erase-it/) [(2)](http://www.computerworld.com/article/2477228/data-privacy/is-overwritten-data-really-unrecoverable-.html) [(3)](http://www.h-online.com/security/news/item/Secure-deletion-a-single-overwrite-will-do-it-739699.html) – timuzhti Apr 21 '16 at 11:35
  • 1
    "scrubs the bad along with the good sectors" is just as necessary for flash as for magnetic disks, and no amount of file copying will ever touch the bad and/or retired blocks – Ben Voigt Oct 11 '16 at 21:38
2

Make a big file full of random data that fills the entire device. Delete it then do it all over again a few times. This should defeat load leveling.

Anonymous
  • 21
  • 1
  • 1
    Write leveling retires blocks that have been written too many times -- these will continue to contain the same information they did when retired (ok it degrades but very slowly) – Ben Voigt Oct 11 '16 at 21:36
  • 1
    This will not defeat rootkits hiding in cells that have been manually designated as damaged (even though they are not damaged) - http://www.blackhat.com/us-13/archives.html#Thomas1 – Ari Trachtenberg Jul 27 '17 at 03:34
1

I can personally reccomend this software; http://www.fileshredder.org/

It is free and it works great, it also has various options for number of times a bit is to be overwritten (it does include templates for several acknowledged standards from DoD etc.)

It works on HDD's and USB's a like and, best of all, is free.

It is Windows only though, I can not see that you specified a OS or filesystem so if you use anything else than Windows this might not be of use to you.

lundzern
  • 111
  • 1
  • What are the merits of this approach? – timuzhti Apr 21 '16 at 07:55
  • It is a software to securely erase files, drives and volumes. It follows acknowledged standards for overwrite cycles and for Windows users, it provides the kind of service that OP was requesting information about. It is only one of many approaches to take, but in a Windows environment this is a software that I have tried and found to work great. Did that answer your question? If not please clarify what, specifically, you want me to answer :) – lundzern Apr 21 '16 at 08:07
  • Well, seeing as there aren't really any good solutions, I think this deserves an upvote, though I'd try to avoid "personally" type answers. Welcome to Information Security Stack Exchange. – timuzhti Apr 21 '16 at 11:33
1

@Damon suggested in a comment to use a hammer. Considering that USB flash drives are now cheap, and that is is hard to guess exactly what the firmware actually does, if I really wanted to securely erase a USB flash drive before disposing it, I would use a heavy hammer to break it into pieces.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
-7

You can use dd (disk destroyer) to write 0s on the whole disk :

dd if=/dev/zero of=/dev/sdb bs=4096

Where /dev/sdb is the path of the mounted partition.

j4v
  • 1
  • 3
  • 1
    My question refers to if overwriting flash drives reliably erases data without the possibility to recover data from it afterwards. – user295031 Jul 06 '14 at 22:09
  • 2
    `dd` doesn't mean `disk destroyer`. Read how the name was probably set up: https://en.wikipedia.org/wiki/Dd_%28Unix%29 – ott-- May 19 '15 at 13:09
  • 2
    This is wrong not only because of what ott says (it doesn't mean disk destroyer), but because a single pass will not overwrite the overprovisioning area. Furthermore, some SSDs will discard strings of 0s, making this effectively a noop, as far as the SSD firmware is concerned. – forest Apr 08 '16 at 08:25
  • 1
    Also I just realized another two lesser problems with this answer, but still problems nonetheless. Not only should you not be wiping a *mounted* partition as you suggest, but /dev/sdb isn't even a partition, it's an entire drive. A partition would be something like /dev/sdb1. – forest Apr 21 '16 at 00:04
  • @forest Do you have a source for the strings of zeroes claim? Genuinely interested in this, and the best way to get around it. – Hashim Aziz Jun 09 '20 at 22:20