[TriLUG] Computer and copier Data Security and Secure Erase

gigaFusion at earthlink.net gigaFusion at earthlink.net
Fri Apr 22 17:04:33 EDT 2011


It may be of general concern to all to know what I have cut-and-pasted 
below:
-------------------------------------------------------------------------------

Tutorial on Disk Drive Data Sanitization
Gordon Hughes, UCSD CMRR (gfhughes at ucsd.edu)
Tom Coughlin, Coughlin Associates (tom at tomcoughlin.com)

Summary: user data is left on disk drives removed from computers and storage 
systems, creating a data security vulnerability that many users are unaware 
of.

Recent Federal and state laws requiring secure erasure of user data expose 
companies to fines of $250,000 and responsible parties to imprisonment for 
10 years.
Complete eradication of user data off drives can be accomplished by running 
data Secure Erasure utilities such as the freeware "HDDerase" downloadable 
here. It executes the Federally-approved (NIST 800-88) Secure Erase command 
in the ATA ANSI standard, which is implemented in all recent ATA drives 
greater than 15-20 GB. A similar command in the SCSI ANSI standard is 
optional and not yet implemented in drives tested. Normal Secure Erase takes 
30-60 minutes to complete. Some ATA drives also implement the standard 
Enhanced Secure Erase command that takes only milliseconds to complete.

-------------------------------------------------------------------------------
That is from the pdf at http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml
where you can also acquire the actual DOS-based program HDDERASE.EXE
to accomplish the Secure Erase of hard disk drives (including SATA), along 
with
all relevant documentation and weblinks for self-support. Instructions and 
resources
are given for creating the necessary DOS boot disk, bootable USB drive, or 
cdrom
boot disk (such as www.bootdisk.com/bootdisk.htm for various DOS versions.)
See also http://www.killdisk.com/ for another perspective on the software.
-------------------------------------------------------------------------------
I note that HDDERASE.EXE was created under funding from the NSA
(National Security Agency), and that many photocopiers contain embedded
disk drives to which this solution is also applicable (with some extra 
effort).
-------------------------------------------------------------------------------
All links are alive as of today, 22 April 2011
Trollz about dirtying hands with dos, etc... go delete yourself!

Regards,
Steve Nixon
------------------------------------------------------------
Why should Corporations and the Super-rich pay taxes at a
much lower rate than other folks? Warren Buffet hints that the
only thing the Rich still need is... to be asked to shoulder
their full responsibilities and pay their fair share of taxes.
They won't volunteer to give it. The People ARE ASKING!
------------------------------------------------------------


> Date: Wed, 20 Apr 2011 12:05:20 -0400
> From: David Both <dboth at millennium-technology.com>
> Subject: Re: [TriLUG] question about data security with vmdks
> To: trilug at trilug.org
> Message-ID: <201104201205.20414.dboth at millennium-technology.com>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> To me it is not so much about the gummint trying to recover my hard drive 
> as it is the folks at the (offshore??) recycling center looking to steal 
> my identity.
>
> I like to use the shred command to delete sensitive data. Shredding means 
> overwriting multiple times with differing bit patterns. It works equally 
> well on a file, a partition, or an entire drive.
>
> shred -u -n 25 /path/to/file
>
> Shreds the file 25 times and unlinks (deletes) it at the end. Beware of 
> the caveats on various types of file systems. See the man page.
>
> shred -n 8 /dev/sdb
>
> Shreds the entire contents of the sdb drive starting at the boot record, 8 
> times.
>
> I just love "everything is a file!"
>
> -- 
>
>
> *********************************************************
> David P. Both, RHCE
> Millennium Technology Consulting LLC
> 919-389-8678
>
> dboth at millennium-technology.com
>
> www.millennium-technology.com
> www.databook.bz - Home of the DataBook for Linux
> DataBook is a Registered Trademark of David Both
>
>
> On Wednesday, April 20, 2011 11:24:38 Alex wrote:
>> My two cents.
>>
>> It's a long running debate as to whether or not zeroing a drive is
>> sufficient to thwart all but theoretical government organizations from
>> recovering information.  The "Great Zero Challenge" comes to mind (
>> http://hardware.slashdot.org/story/08/09/06/189248/The-Great-Zero-Challenge-Remains-Unaccepted).
>> In
>> my opinion, you'd need a scanning electron microscope (or some similar 
>> scale
>> probing device) to recover a drive that has been zeroed, and do you have
>> data worth that cost?  If you're absolutely worried about it, then dd it
>> with /dev/urandom a couple times... theres no coming back from that.
>>
>> It should be noted that VMDKs are not encrypted, they're well documented,
>> and they aren't particularly different from just a plain-Jane disk 
>> (beyond a
>> bit of muxing to make a VM happy when running from one) so if you have a
>> half intelligent recovering scheme you'll pick up data that hasn't been
>> overwritten with no particular problem.  A potential solution is to have
>> your VMs run encrypted FSs inside their VMDK file, and you could even
>> encrypt the disk they're sitting on, but that's still theoretically
>> recoverable with a smidgen of computation (read: the future will render
>> all  "present" cryptography moot).  Not to mention that you'll have a
>> performance hit (though I don't know if this is acceptable in your
>> environment).
>>
>> As has been mentioned, formatting doesn't particularly erase data... all 
>> it
>> does is remove references that the filesystem uses to point to things. 
>> If
>> you use an arbitrarily random hashing algorithm which is built on a per 
>> disk
>> basis to distribute data around the disk (as one filesystem or two may 
>> have
>> done...) this would theoretically be a valid solution... but most any 
>> modern
>> filesystem will still be recoverable provided you have the proper 
>> heuristic
>> approach to data recovery.
>>
>> To paraphrase Bill Farrow's elegant response: You'll sleep better at 
>> night
>> if you make some effort to shred your data.
>>
>> ~Alex Kesling
>>
>> On Wed, Apr 20, 2011 at 10:22 AM, Igor Partola <igor at igorpartola.com> 
>> wrote:
>>
>> > You could also use badblocks in write mode, where it will by default
>> > use patterns like 0x00, 0x55, 0xaa, and 0xff. This always made me feel
>> > better about recycling drives. Then again, I am no data recovery
>> > expert. Maybe some random noise would be better than uniform patterns.
>> >
>> > Igor
>> >
>> > On Wed, Apr 20, 2011 at 9:57 AM, William Chandler 
>> > <wcchandler at gmail.com>
>> > wrote:
>> > > You need to overwrite the previous data.  Simple re-formatting will 
>> > > not
>> > do
>> > > this.  Most data will still be accessible by using various tools --
>> > PhotoRec
>> > > comes to mind.
>> > >
>> > > As somebody else suggested, DBan will do fairly well.  An alternative 
>> > > is
>> > to
>> > > dd if=/dev/zero of=/dev/whatever.  It should take a long time.
>> > > -- 




More information about the TriLUG mailing list