[ale] really really deleting files....

[Keith R. Watson]

At 04:22 PM 6/24/2003 -0400, you wrote:
> >
>A better (ahem) solution might be to use HCl. The platter surface is

James,

Great pun.


>Ferrous Oxide known to most normal humans as rust. Hydrochloric acid is
>a very effective rust remover. As the casing metal is usually aluminum,
>the acid will work itself to death converting the aluminum to AlCl, a
>harmless salt.
>
>I don't think it would be possible to reassemble the dissolved FeO2 and
>recover any magnetic domains.


I see your point. My chemistry basics are a bit rusty (pun intended).


>But the issue as posed is more "How to securely recycle a hard drive".

This very issue was discussed on one the mail lists here at work.


>My (untested) solution (using no caustic chemicals):
>
>For i in 0 1 2 3 4 5 6 7 8 9 do
>startblock=$(9-$i)
>dd if=/dev/random of=<ramdisk>/block bs=1048576 count=1
>dd if=<ramdisk>/block of=/dev/hdx obs=1 ibs=3 seek=$i skip=$startblock
>done
>
>This would take a while with a 200G hard drive :)

When I first read the Rainbow book requirements for secure erasure (DOD 
wipe), I thought, "How hard could it be to write a program to do this?" 
They discuss writing to *all* locations of the disk including blocks that 
are marked as unusable. fsck can mark a block bad that was previously used 
to store data. The data in the bad block can still be recovered even though 
the block is unreliable for long term storage.

Your script would seem to address all blocks on the drive. However, this 
will only address blocks presented by the drives firmware as addressable. 
In reality disk drives have reserve blocks that are swapped at a hardware 
level for blocks that are found to be bad after manufacture. This is 
independent of fsck. If data was stored in one of the hardware reallocated 
blocks then it still exists and can be recovered using the right software 
and hardware. As far as I know, commercial "wipe" programs don't handle 
this either. The Rainbow books specify that a DOD wipe is only effective if 
a disk controller is used that can address *every* location on the hard drive.

Then I read Peter's paper.

http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

In Section 3 - "Erasure of Data stored on Magnetic Media", Peter discusses 
the impact that RLL encoding has on the erasure process. The bit pattern 
used must take into account the effect RLL encoding has on the magnetic 
domain sequence on the disk's surface. It is not enough to write over all 
currently encoded regions, the current state must be flipped multiple times 
and then it must be left in a random state. This requires multiple passes 
with a very carefully selected bit pattern. The Rainbow books don't specify 
what algorithm or bit pattern to use. The National Industrial Security 
Program Operating Manual (NISPOM), DoD 5220.22-M, January 1995 only states:

http://www.dss.mil/isec/nispom_0195.htm
"d. Overwrite all addressable locations with a character, its complement, 
then a random character and verify. IHIS METHHOD IS NOT APPROVED FOR 
SANITIZING MEDIA THAT CONTAINS TOP SECRET INFORMATION."

Peter's paper then goes on to state that even when a "good" bit pattern is 
used and all areas are flipped multiple times and randomized, it is still 
possible to recover data using magnetic force microscopy (MFM). Which is 
why the Rainbow books says that the correct process for secure destruction 
of "sensitive" data is as follows:

1. Do a DOD wipe using a special controller that will write to every 
possible location.

2. Physically destroy the media by grinding it up.

Then, and only then, is the data truly un-recoverable by any means. Given 
that the Rainbow books are aimed at military and government security I can 
understand their paranoia.

The bottom line is that we have an obligation to protect the security of 
the data we manage. To do that we have to weigh the risk of release against 
the costs of securing it. All I have attempted to do is lay out *all* the 
risks so that we can make an informed assessment.

For the kind of data that I typically handle, simply wiping the drive with 
a "DOD wipe" program is more than sufficient, even though a special 
controller was not used. Our goal is to recycle the hardware for future use 
while preventing an unintended release of data.

So far I have been using Ghost gdisk. It has a built in DOD wipe function. 
The UNIX wipe command also seems to work but it does come with this caveat:

http://abaababa.ouvaton.org/wipe/wipe.1.html
"Wiping over NFS or over a journalling filesystem (ReiserFS etc.) will most 
probably not work. Therefore I strongly recommend to call wipe directly on 
the corresponding block device with the appropriate options. However THIS 
IS AN EXTREMELY DANGEROUS THING TO DO. Be sure to be sober. Give the right 
options. In particular : don't wipe a whole harddisk (eg. wipe -kD /dev/hda 
is bad) since this will destroy your master boot record. Bad idea. Prefer 
wiping partitions (eg. wipe -kD /dev/hda2) is good, provided, of course, 
that you have backed up all necessary data."

The part that still bothers me is that Peter's paper made it very clear 
that not just any bit pattern will do the trick. So how do I know that a 
vendors product is using a good bit pattern? My moto is, "If the vendors 
lips are moving, they are lying" My job is to discover what their product 
really does despite their help. I have yet to find any reviews of this kind 
of product. If you know of any, please let me know.

In the mean time I'll continue to use gdisk and wipe.

keith

-------------

Keith R. Watson                        GTRI/ITD
Systems Support Specialist III         Georgia Tech Research Institute
keith.watson at gtri.gatech.edu           Atlanta, GA  30332-0816
404-894-0836

_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale