Agreed. It is simply cryptographically infeasible to break modern encryption, assuming that a) the password is long & as close to being truly random as possible (one reason why user-selected passwords by themselves are a dreadful idea, vs a hardware token or multi-factor), and b) there does not exist a s/w flaw that allows an attacker to bypass the lengthy computation associated with brute force encryption attacks.
Most thieves probably steal laptops with the intent of getting the hardware (juicy data being a nice bonus). If a knowledgable thief wanted to steal data, he'd probably *not* steal the laptop & instead try to engage in an online attack strategy instead, like planting a backdoor on the target machine (exploiting a buffer overrun vulnerability, or whatever). The hardware would never be stolen, since the data itself is the target, not the hardware. Again, most thieves have neither the knowledge nor the patience to attack in this fashion; they steal the h/w and, if there's reasonably accessible data, then it's a jackpot. Otherwise, well, at least they got some slick new hardware. I've thrown out some general tips in the recent past to reduce one's online attack surface area so I won't reiterate (& I guess it's probably off-topic). - Garrett ----- Original Message ----- From: "Michael Jardine" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, July 23, 2007 2:05 PM Subject: Re: [FDE] Data at Rest, Data in Transit, and Data in Use > Pete, > > A brute force attack on an AES-256 encrypted drive that has a STRONG > "Password" or Key would take years. Of course, no one could prevent a > brute-force attack if the attacker gained physical access to the drive in > question - however if the users password (and thus the key) isn't 12345678 > or some other Dilbertian string, then it's realistically impossible to > retrieve the key in a reasonable time frame. > > > Regards, > Michael > ________________________ > Michael Jardine > SECUDE IT Security - Seattle > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Pete Jansson > Sent: Monday, July 23, 2007 9:44 AM > To: [email protected] > Subject: Re: [FDE] Data at Rest, Data in Transit, and Data in Use > > 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 > > _______________________________________________ > 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
