To extend on my last email, I wonder why people think there is a need to use secure deletion/wiping utilities on devices that are full-disk-encrypted. Clearing the paging files and doing freespace wipes seem unnecessary to me if the device itself contains only ciphertext anyway. One could argue that a full disk wipe is still necessary when de-commissioning drives... but why is that necessary? It seems more than sufficient to just delete the keys that allow access to that device, making the data stored on that drive no more useful than random bits. If there is a concern that a key has been compromised, then I recommend changing the key and revoking the old key, not doing a full disk wipe.
Given the availability and affordability of good FDE solutions, the more intricate and tedious solutions of the past seem unnecessary and less efficient. - Garrett ----- Original Message ----- From: "Garrett M. Groff" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, July 23, 2007 12:04 PM Subject: Re: [FDE] Data at Rest, Data in Transit, and Data in Use > Using an FDE solution on the primary drive (on which the OS is installed) > would resolve the problem of temporary files, paging files, and the > hibernation file since the data in those files (and all other files on the > disk) will be encrypted. Any secondary drives should also be encrypted if > they contain confidential data. Further, removable drives and USB > solid-state devices can be encrypted (probably with the same FDE solution > used to encrypt the primary drive). Hence, any data written to those > devices > is also encrypted, affording a high level of security. > > > ----- Original Message ----- > From: "Curt Wilson" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Monday, July 23, 2007 10:51 AM > Subject: Re: [FDE] Data at Rest, Data in Transit, and Data in Use > > >> >>>> This means two things: ... save only the encrypted files long term, >>>> >AND use a full disk file scrubbing utility >>>> >religiously, to get rid of all of the temp files and other garbage as >>>> >quickly as possible. >>> >>> Encrypted virtual partitions automatically accomplish the first of >>> these and obviate the need for the second. >>> >> >> I appreciate the discussion however this last message appears to gloss >> over some details, or perhaps I just don't understand deeply enough. >> >> How exactly does an encrypted virtual partition obviate the need for the >> second ("get rid of temp files")? Doesn't Windows and various Windows >> apps stash temp files in the various "Documents and Settings" (XP), and >> "Users" directories? And also stash items in the page file? Do you >> suggest encrypting the page file within an encrypted virtual partition? >> How about the hibernation file? Clearing the pagefile at shutdown works, >> and protects against a "data at rest" attack, but what about while the >> OS is running and in-use? >> >> Perhaps there is a way to protect the data with encrypted virtual >> partitions but how does it address these particular concerns? Perhaps >> Windows, and every app, could be tweaked to use some environment vars >> for temp location (maybe this is already done) and we could modify that >> location to be within the encrypted virtual partition. We might then >> have to activate the encrypted virtual partition at boot, in case the OS >> wants to also use that space and can't find it because it's not yet >> decrypted. Perhaps that's where a hardware token would come into play >> post-boot, pre-login? >> >> Clearly FDE has it's place for protecting data at rest. >> >> If vendors are going to respond to me privately, please address these >> questions specifically. Thanks >> >> Have a great day >> >> >> >> >> Mike Markowitz wrote: >>> Bob: I quite enjoyed your last note... sounds like it'll be an >>> worthwhile >>> talk. I'd like to see you add one idea, though... >>> >>> At 01:33 PM 7/20/2007, Robert Jueneman wrote: >>>> FDE is probably the only solution for the Data at Rest >>>> problem that everyone is currently focused on, i.e., when the computer >>>> is turned off. >>> >>> Not quite: encryption of a virtual disk containing all sensitive data >>> on the system would also work. (There are good reasons NOT to encrypt >>> the >>> OS and program files.) >>> >>>> make sure that there is NO plaintext exposed >>>> on the computer for any longer than is absolutely necessary. >>> >>> Exactly the reason to use an encrypted virtual partition with a device >>> driver that only presents plaintext to applications (running under an >>> authorized user's login process) *via RAM* and ensures that only >>> ciphertext is written to disk. You simply 'mount' the partition when >>> you need access to the data and 'unmount' it when you're finished. >>> (If you're really clever, you automate the mounting and unmounting >>> processes, possibly with integrated user authentication.) >>> >>>> This means two things: ... save only the encrypted files long term, >>>> AND use a full disk file scrubbing utility >>>> religiously, to get rid of all of the temp files and other garbage as >>>> quickly as possible. >>> >>> Encrypted virtual partitions automatically accomplish the first of >>> these and obviate the need for the second. >>> >>>> [with regard to file encryption] Unfortunately, really large files can >>>> become rather cumbersome to deal with, and particularly the .pst files >>>> created by Outlook - some of which can grow to 4 GB. >>> >>> Bob, I love you! This is the BEST reason to use a device driver that >>> performs application-transparent decryption 'on the fly' for all *block* >>> reads (by authorized applications), and encryption for block writes. >>> This way there's never any need to need decrypt an entire file. >>> >>> Always happy to see you motivating the adoption and use of our products! >>> >>> Regards, >>> >>> -mjm >>> >>> _______________________________________________ >>> FDE mailing list >>> [email protected] >>> http://www.xml-dev.com/mailman/listinfo/fde >>> >> >> >> -- >> Curt Wilson >> IT Network Security Officer >> Southern Illinois University Carbondale >> 618-453-6237 >> >> GnuPG key: http://www.infotech.siu.edu/security/curtw.pub.asc >> >> _______________________________________________ >> FDE mailing list >> [email protected] >> http://www.xml-dev.com/mailman/listinfo/fde >> > > _______________________________________________ > FDE mailing list > [email protected] > http://www.xml-dev.com/mailman/listinfo/fde > _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde
