Often, we’re told that if we are looking to secure data on hard drives or removable media, that we must encrypt that data. This will ensure that if our laptops or thumb drives get lost or stolen, or even when we are travelling abroad, that our data will be secured from prying eyes.
Well, if that is truly the case, then why are we expected to jump through so many hoops when it comes to media sanitization? Are we just looking to wipe the data from a drive, and then repurpose it to another user for further use? What is the value of the data (classification)? If we’re just looking to turn over the drive for re-use, then why are basic media sanitization standards so complex?
Government restrictions aside, the most accepted method of “wiping” a hard drive for re-use includes first writing all zeros to the drive and then writing random or pseudorandom data to the drive.
This is just too damn slow.
And, today’s media sanitization documentation reads like a conspiracy theorist’s manifesto:
See: http://forums.anandtech.com/showthread.php?t=2040453 – FOR PARANOIA
So, what if we just encrypt the entire hard drive with a randomly generated key that never gets stored anywhere? Isn’t total drive encryption an already accepted method to secure our sensitive data from thieves and spies?
Of course, this is not an original idea:
As Bruce Schneier (noted security blogger and author of “Applied Cryptography”) states, “…. either a fully encrypted computer is secure — or it’s not. If it’s not good enough to consider the data gone – (if you encrypt the drive and destroy the key) – why depend on it to keep your data secure while it’s on your desk or wherever?”
There are several applications dedicated to the function of media sanitization. The most popular of these, and an accepted standard in the security community is a freeware program called, “Derek’s Boot and Nuke” (DBAN). While DBAN offers many methods to wipe a hard drive, it can take hours, and even days (depending on the size of the drive) to complete even the most basic hard drive wiping functions.
But, if we simply just encrypt the drive – a single pass encryption with a random key (or even a pseudorandom key) using a cryptographically secure algorithm – our data will be as secure as though it were wiped with a fancy multi-pass application.
Here’s a solution to the speed issue: Boot a linux kernel and run OpenSSL.
OpenSSL is native to the linux 2.6 kernel, so all one needs to do is a run linux live-boot from CD or USB drive, and then run OpenSSL from a command prompt.
The OpenSSL command-line binary that ships with the OpenSSL libraries can perform a wide range of cryptographic operations.
First, let’s look at some algorithm benchmarking in this arena. OpenSSL developers have created and included a benchmarking suite directly into the OpenSSL binary. It’s accessible via the “speed” option. It tests how many operations it can perform in a given time, rather than how long it takes to perform a given number of operations.
From the command prompt, run: openssl speed
There are two sets of results. The first reports how many bytes per second can be processed for each algorithm, the second the times needed for sign/verify cycles. Here are the results on an 2.16GHz Intel Core 2.
The ‘numbers’ are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md2 1736.10k 3726.08k 5165.04k 5692.28k 5917.35k
mdc2 0.00 0.00 0.00 0.00 0.00
md4 18799.87k 65848.23k 187776.43k 352258.73k 474622.63k
md5 16807.01k 58256.45k 160439.13k 287183.53k 375220.91k
hmac(md5) 23601.24k 74405.08k 189993.05k 309777.75k 379431.59k
sha1 16774.59k 55500.39k 142628.69k 233247.74k 288382.98k
rmd160 13854.71k 40271.23k 87613.95k 124333.06k 141781.67k
rc4 227935.60k 253366.06k 261236.94k 259858.09k 194928.50k
des cbc 48478.10k 49616.16k 49765.21k 50106.71k 50034.01k
des ede3 18387.39k 18631.02k 18699.26k 18738.18k 18718.72k
idea cbc 0.00 0.00 0.00 0.00 0.00
rc2 cbc 19247.24k 19838.12k 19904.51k 19925.33k 19834.98k
rc5-32/12 cbc 0.00 0.00 0.00 0.00 0.00
blowfish cbc 79577.50k 83067.03k 84676.78k 84850.01k 85063.00k
cast cbc 45362.14k 48343.34k 49007.36k 49202.52k 49225.73k
aes-128 cbc 58751.94k 94443.86k 111424.09k 116704.26k 117997.57k
aes-192 cbc 53451.79k 82076.22k 94609.83k 98496.85k 99150.51k
aes-256 cbc 49225.21k 72779.84k 82266.88k 85054.81k 85762.05k
sha256 9359.24k 22510.83k 40963.75k 51710.29k 56014.17k
sha512 7026.78k 28121.32k 54330.79k 86190.76k 104270.51k
sign verify sign/s verify/s
rsa 512 bits 0.000522s 0.000042s 1915.8 23969.9
rsa 1024 bits 0.002321s 0.000109s 430.8 9191.1
rsa 2048 bits 0.012883s 0.000329s 77.6 3039.6
rsa 4096 bits 0.079055s 0.001074s 12.6 931.3
sign verify sign/s verify/s
dsa 512 bits 0.000380s 0.000472s 2629.3 2117.9
dsa 1024 bits 0.001031s 0.001240s 969.6 806.2
dsa 2048 bits 0.003175s 0.003744s 314.9 267.1
You can run any of the algorithm-specific subtests directly:
For instance, to test rc4 speeds:
openssl speed rc4
For the purposes of wiping data from a hard drive that would be unrecoverable from the average computer user, nearly any of these algorithms would be sufficient. But, if you are slightly paranoid (but not bound to government restrictions), RC4 should be sufficient (and benchmarks the fastest). Remember, we’re talking about sanitizing a personal or a corporate hard drive for the possibility of repurposing it – not hiding confidential secrets from potential “Enemies of the State.” The DoD standard of grinding a physical drive into metallic crumbs, and then heating up the fragmented bits into a molten lava is still the most secure method of hard drive sanitization where top secret data is concerned. The reasoning behind this is that rendering the drive into base metal slag will thwart most attempts to recover data through forensic analysis – even utilising an advanced technique to recover magnetic data on the drive called, “Magnetic Force Microscopy”.
But, to date, no one has proven that data that has been wiped with a randomized single pass can be recovered by Magnetic Force Microscopy, or any advanced methodology (this doesn’t rule out that certain advanced *and expensive* technologies to recover data really exist).
So, here’s how to wipe (or rather randomly encrypt) your data storage device:
Wiping the entire hard drive with an OpenSSL encryption routine:
After booting with a live linux distro, run from the command prompt:
dd if=/dev/random bs=1k count=1 | openssl enc -kfile /dev/fd/0 -in /dev/zero -rc4 -out filename
This will create a file and just keep filling it with data until the partition or drive is full.
You can simply delete the file after the operation is complete:
rm -f filename
If you feel the need to use another algorithm, replace “rc4” with your algorithm of choice.
You might also use a linux kernel module random number generator known as “frandom”: https://wiki.archlinux.org/index.php/Frandom (there are some good benchmarking comparisons to other methods of drive wiping at this site).
Simple tests using this method of sanitization vs. the accepted standard drive-wiping applications show it to be (in some cases) 60 times faster.
Remember, the point of this is that if full drive encryption is considered “secure” for travel, loss, and theft, then it should be considered just as secure for media sanitization.