zfs discuss - Dec 2006 - [security-discuss] Re: Thoughts on ZFS Secure Delete - without using Crypto

I''ve heard from old-old-oldtimers, back in the epoxy-disk days, that
even after this type of erase the old epoxy disks could sometimes be
read via etching combined with electron microscopes -- the (relatively) new
sputtered aluminum finishes probably changed that.  So back in the epoxy days,
disks could never move down in classification, they were always either
kept at the same or higher classification or else  bathed in acid until
no more coating remained.  Or slagged.

I can see why gov''t customers would ideally like a better solution but
I know that in my disk drive programming days, an alternate disk controller
had to be used in order to do such things, and I hear that''s still the
case,
except that since disk controllers are little teensy chips instead of
refrigerator-sized external boxes, it might not be worth the money to bother
trying to get the disk factories to do this. 

What might be doable is to get someone to manufacture a disk where this
is controlled by a jumper (even a hidden, covered, jumper) so that the
jumper could be moved instead of trying to pry chips out of the card in
order to replace the controller logic.

Bottom line: if all I hear is true, it is the drive manufacturers who are
in a position to address this.

>Date: Wed, 20 Dec 2006 15:32:48 -0800 (PST)
>From: Gary Winiger <gww at eng.sun.com>
>Subject: Re: [security-discuss] Re: [zfs-discuss] Thoughts on ZFS Secure	
Delete - without using Crypto
>To: James.Hughes at Sun.COM, sommerfeld at Sun.COM
>Cc: zfs-discuss at opensolaris.org, security-discuss at opensolaris.org
>Delivered-to: security-discuss at opensolaris.org
>X-Original-To: security-discuss at opensolaris.org
>List-Unsubscribe:  
<http://mail.opensolaris.org/mailman/listinfo/security-discuss>, 
<mailto:security-discuss-request at
opensolaris.org?subject=unsubscribe>
>List-Id: OpenSolaris Security Discussions
<security-discuss.opensolaris.org>
>
>> On Wed, 2006-12-20 at 03:21 -0800, james hughes wrote:
>> > This would be mostly a "vanity erase" not really a
serious "security
>> > erase" since it will not over write the remnants of remapped
sectors.
>> 
>> Yup.  As usual, your milage will vary depending on your threat model.  
>> 
>> My gut feel is that there''s a cost-benefit sweet spot near a
mechanism
>> which provides for the prompt overwrite of recently deallocated blocks
>> with either zeros or newly allocated data, with more intensive
bleaching
>> reserved for when disks are taken out of service. 
>
>	When SunFed first implemented format->analyze->purge to the
>	Magnetic Remnance specification of, IIRC, 3 overwrites each of
>	0000, 5555, AAAA, the instructions to the admins went something
>	like:  When you first put the disk in service, record the factory
>	flaw map and retain it.  When you later purge the disk, read out
>	and record the current flaw map.  Purge the disk.  If the factory
>	flaw map and current flaw map differ, remap the difference to
>	active and re-purge the disks.
>	I''ve been told, but haven''t verified, that the current
format -
>	disk driver - disk combinations no longer support both reporting the
>	flaw map and remapping flawed sectors back to active.
>
>Gary..
>_______________________________________________
>security-discuss mailing list
>security-discuss at opensolaris.org