>> 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
