If someone gets physical custody of the drive, even without the keys, what's to prevent brute-force attacks against the assets? I don't understand why "losing" the keys is considered a data protection strategy.
On 7/23/07, Garrett M. Groff <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde
