Anyone here know much about how the ZFS "secure deletion" will fully wipe the traces of deleted files or know to what degree or standard the secured delete will be designed to comply with? Anticipated release date? Solaris 10 update4? TIA RE page 30 of 34: http://www.opensolaris.org/os/community/zfs/docs/zfs_last.pdf This message posted from opensolaris.org
Wes Williams wrote:> Anyone here know much about how the ZFS "secure deletion" will fully wipe the traces of deleted files or know to what degree or standard the secured delete will be designed to comply with?It will come as part of phase 2 of the crypto support.> Anticipated release date? Solaris 10 update4?There isn''t even a completed design yet so there is NO change at all that it will be in S10u4. It this time I''m not even planning on having any crypto support backported to any Solaris 10 update release. -- Darren J Moffat
Thanks for the update! This message posted from opensolaris.org
Darren J Moffat wrote:> Wes Williams wrote: > >> Anyone here know much about how the ZFS "secure deletion" will fully >> wipe the traces of deleted files or know to what degree or standard >> the secured delete will be designed to comply with? > > > It will come as part of phase 2 of the crypto support.Dp you know if you will be targetting any official government standards? Darren
Darren Reed wrote:> Darren J Moffat wrote: > >> Wes Williams wrote: >> >>> Anyone here know much about how the ZFS "secure deletion" will fully >>> wipe the traces of deleted files or know to what degree or standard >>> the secured delete will be designed to comply with? >> >> >> It will come as part of phase 2 of the crypto support. > > > Dp you know if you will be targetting any official government standards?I''m not ware of any official government standards for secure deletion based purely on always encrypt the data and destroy the key. If you know of any please send references. -- Darren J Moffat
Darren, The most common standard I''m aware of is the US: DOD 5220.22-M The latest NISPOM (Feb. 2006) can be found here (temporarly unavailable): http://www.dss.mil/whatsnew/nispom06.htm Other resources: http://www.dss.mil/isec/nispom.pdf (older version of NISPOM) http://en.wikipedia.org/wiki/DOD_5220.22-M http://www.google.com/search?complete=1&hl=en&lr=&safe=off&q=DOD+5220.22-M&btnG=Search http://www.zdelete.com/dod.htm Although I don''t have any direct affiliation with any of these entities or standard, please let me know if I may help in any way. Regards, Wes Williams This message posted from opensolaris.org
Wes Williams wrote:> Darren, > > The most common standard I''m aware of is the US: DOD 5220.22-M > > The latest NISPOM (Feb. 2006) can be found here (temporarly unavailable): > http://www.dss.mil/whatsnew/nispom06.htmSeems like that document has gone AWOL! Also that document is about erasing after the fact by "over writing". Thats a different solution to what the we are proposing for ZFS which is to remove that need and just destroy the key instead (which obviously isn''t stored on the same disk as the file system data). We already have support in the format(1m) command in Solaris for that style of "secure deletion" http://www.sun.com/software/solaris/trustedsolaris/ts_tech_faq/faqs/purge.xml Note that even though that page is marked for Trusted Solaris the exact same code is used in Solaris. -- Darren J Moffat
> DarrenM wrote: > > Wes Williams wrote: > > Darren, > > > > The most common standard I''m aware of is the US: DOD 5220.22-M > > > > The latest NISPOM (Feb. 2006) can be found here (temporarly unavailable): > > http://www.dss.mil/whatsnew/nispom06.htm > > Seems like that document has gone AWOL! > > Also that document is about erasing after the fact by "over writing". > Thats a different solution to what the we are proposing for ZFS which > is to remove that need and just destroy the key instead (which > obviously isn''t stored on the same disk as the file system data). > > We already have support in the format(1m) command in Solaris for that > style of "secure deletion" > > http://www.sun.com/software/solaris/trustedsolaris/ts_tech_faq/faqs/purge.xml > > Note that even though that page is marked for Trusted Solaris the > exact same code is used in Solaris. > > -- > Darren J Moffat > >Darren M., I hope we?re on the same page here. Of course the encrypted ZFS file system is in the works and will be very important to government and several industries, and I suppose the deletion of encrypted files by simply losing an encryption key as you suggest sounds quite efficient and reasonable. Please clarify your ?support in the format(1m) command? as referenced from Trusted Solaris ? does it now work on ZFS filesystems as well? Perhaps in the future? Or, only on UFS now and forever? My original question didn?t explicitly state a non-encrypted file system, but that was my primary concern with this thread ? unencrypted ZFS file system secure file deletion ? prior to hearing about the ?format(1m)? command from Trusted Solaris and potential use on ZFS file systems. I understand many would think that if it?s important it should be encrypted anyway, and that is also my opinion as well. I?m also hopeful the ZFS encryption will be so fast and easy enough most users would simply use it as default. This is where I hope the majority of ZFS security efforts be employed. Thanks again for clearing this up. This message posted from opensolaris.org
Wes Williams wrote:> I hope we?re on the same page here. Of course the encrypted ZFS file system is in the works and will be very important to government and several industries, and I suppose the deletion of encrypted files by simply losing an encryption key as you suggest sounds quite efficient and reasonable. > > Please clarify your ?support in the format(1m) command? as referenced from Trusted Solaris ? does it now work on ZFS filesystems as well? Perhaps in the future? Or, only on UFS now and forever?No it doesn''t work on ZFS file systems or even on UFS ones. Why ? because it doesn''t work at the file system layer at all it works at the disk layer (or really the layer the device layer which depending on the type of storage you have may or may not be a real single physical disk). So the analyze/purge functionality in format(1m) CAN be used to "securely delete" content of a ZFS file system by acting on the components of the pool. What we gain by using a crypto file system and key destruction is that you can destroy individual ZFS data sets at will (or using an external semi-trusted key manager at predetermined time points) rather than destroying at the device layer. Also it isn''t from Trusted Solaris at all it has always been in Solaris it is just that the FAQ entry I used as a reference happens to be part of the Trusted Solaris FAQ because it was those customers that asked about this most. -- Darren J Moffat
Darren J Moffat wrote:> Wes Williams wrote: > >> Darren, >> >> The most common standard I''m aware of is the US: DOD 5220.22-M >> >> The latest NISPOM (Feb. 2006) can be found here (temporarly >> unavailable): >> http://www.dss.mil/whatsnew/nispom06.htm > > > Seems like that document has gone AWOL! > > Also that document is about erasing after the fact by "over writing". > Thats a different solution to what the we are proposing for ZFS > which is to remove that need and just destroy the key instead (which > obviously isn''t stored on the same disk as the file system data).Ah, when I read that you were doing secure deletion of data, I wasn''t aware that this implied the use of cryptography to encrypt the data as well. But I suppose "secure deletion of data" isn''t the same as "secure files deletion." Darren
I didn''t mean to imply encryption of data because the original concern was for a means to securely sanitize unencrypted files on an unencrypted ZFS pool. Ideally this could be done without having to wipe a drive, but that''s not the impression I''ve received thus far. This message posted from opensolaris.org
Wes Williams wrote:>I didn''t mean to imply encryption of data because the original concern was for a means to securely sanitize unencrypted files on an unencrypted ZFS pool. Ideally this could be done without having to wipe a drive, but that''s not the impression I''ve received thus far. > >Right, you''ve interpreted the subject line the way in which I did. I think that in itself should be a message to Darren M. :) I think he means the subject to be: encrypted file deletion and what we''re both concerned about isn''t that at all :) Darren
I suspect that nuking all copies of the key that you know about isn''t going to satisfy the truly paranoid. They''ll probably want a filesystem-level or pool-level option which causes ZFS to overwrite blocks using the "approved" method (zeros, ones, random bits) as they''re freed. Until someone implements that: Remember that ZFS mirroring only copies allocated data. If you have a spare wiped disk, you could, hypothetically (I haven''t tried this!) - zpool replace a disk in the pool - wipe the replaced disk with the secure format overwrite discussed earlier on this thread You are now back where you started, with a spare, wiped disk. Repeat this until you''ve hit all disks in the pool. All blocks free at the time of the start of this exercise will have been wiped. - Bill