[FDE] Data at Rest, Data in Transit, and Data in Use
Michael Jardine
michael.jardine at usa.secude.com
Mon Jul 23 12:05:22 MDT 2007
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: fde-bounces at www.xml-dev.com [mailto:fde-bounces at www.xml-dev.com] On
Behalf Of Pete Jansson
Sent: Monday, July 23, 2007 9:44 AM
To: fde at www.xml-dev.com
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 <groffg at gmgdesign.com> 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" <groffg at gmgdesign.com>
> To: <fde at www.xml-dev.com>
> 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" <curtw at siu.edu>
> > To: <fde at www.xml-dev.com>
> > 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
> >>> FDE at www.xml-dev.com
> >>> 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
> >> FDE at www.xml-dev.com
> >> http://www.xml-dev.com/mailman/listinfo/fde
> >>
> >
> > _______________________________________________
> > FDE mailing list
> > FDE at www.xml-dev.com
> > http://www.xml-dev.com/mailman/listinfo/fde
> >
>
> _______________________________________________
> FDE mailing list
> FDE at www.xml-dev.com
> http://www.xml-dev.com/mailman/listinfo/fde
>
_______________________________________________
FDE mailing list
FDE at www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
More information about the FDE
mailing list