Whole disk encryption

On 5-Dec-2008, at 07:26, Roland Whitehead wrote:
> Following Joe Kissell's excellent article "Securing Your Disks with
> PGP Whole Disk Encryption" [1] we have been looking at securing our
> 10.5 MacBooks in case they do get stolen or lost. We have
> implemented most of the hardening suggestions made by Daniel
> Cuthbert of Corsaire [2] but do want to find some way of encrypting
> our disks.

Really? There's a reason to encrypt /System and /Library and /private/
var/logs/ ?? Why isn't it enough to encrypt the user space where all
the file and data lives?

I'm all for encryption and securing laptops, but encrypting the entire
contents of the disk seems like overkill to me.

On 12/6/08 9:24 AM, "LewisGmail" <gkremegmail.com> wrote:

>> Following Joe Kissell's excellent article "Securing Your Disks with
>> PGP Whole Disk Encryption" [1] we have been looking at securing our
>> 10.5 MacBooks in case they do get stolen or lost. We have
>> implemented most of the hardening suggestions made by Daniel
>> Cuthbert of Corsaire [2] but do want to find some way of encrypting
>> our disks.
>
> Really? There's a reason to encrypt /System and /Library and /private/
> var/logs/ ?? Why isn't it enough to encrypt the user space where all
> the file and data lives?
>
> I'm all for encryption and securing laptops, but encrypting the entire
> contents of the disk seems like overkill to me.

Spool files contain sensitive information and aren't always purged. /var/db
contains all kinds of sensitive information.

/etc the same way.

There are valid arguments for WDE.

--
John C. Welch

--On December 6, 2008 6:24:52 AM -0800 "LewisGmail" <gkremegmail.com>
wrote:

> Really? There's a reason to encrypt /System and /Library and /private/
> var/logs/ ?? Why isn't it enough to encrypt the user space where all
> the file and data lives?
>
> I'm all for encryption and securing laptops, but encrypting the entire
> contents of the disk seems like overkill to me.

With file vault the saved state of your document is stored encrypted.
While you're working on it however the editing program may store temporary
copies in locations other than your home directory. and if the OS pages out
to disk some of the memory used by your editing program, including the
document itself. Paged memory is definitely stored outside of your home
directory.

If you allow your computer to go into hibernation mode, the entire contents
of memory is written to your hard drive, outside of your home directory.
The memory contents may include unencrypted copies of documents or maybe
even the decryption keys themselves.

An extreme form of this attack (that even whole disk encryption isn't safe
from) is where they freeze the memory chips to slow decay of RAM, pop that
into a computer and read out the contents. If you've written out memory to
an unencrypted disk they have all the time in the world to scan what was in
your computer's memory.

<http://www.sciencedaily.com/releases/2008/02/080221105820.htm>

On 7-Dec-2008, at 18:07, Kevin van Haaren wrote:
> Paged memory is definitely stored outside of your home directory.

And can be stored encrypted.

> If you allow your computer to go into hibernation mode, the entire
> contents
> of memory is written to your hard drive,

encrypted

System Preferences -> Security -> General -> Use secure virtual memory

On Dec 7, 2008, at 7:07 PM, Kevin van Haaren wrote:

> An extreme form of this attack (that even whole disk encryption
> isn't safe
> from) is where they freeze the memory chips to slow decay of RAM,
> pop that
> into a computer and read out the contents. If you've written out
> memory to
> an unencrypted disk they have all the time in the world to scan what
> was in
> your computer's memory.
>
> <http://www.sciencedaily.com/releases/2008/02/080221105820.htm>

I suppose in the recent study cited in the article, it would be rather
difficult to perform this kind of security breach on a MacBook Air,
since the ram is not removable. Maybe that's a selling point for the
MacBook Air?

Jeffrey

On 8/12/2008 2:07 PM, "Kevin van Haaren" <kevinvanhaaren.net> spake thus:

> An extreme form of this attack (that even whole disk encryption isn't safe
> from) is where they freeze the memory chips to slow decay of RAM

And if the recently-discovered memristor technology takes off, in a few
years time they won't even need to do that:

<http://www.spectrum.ieee.org/dec08/7024>

--
Nigel Stanger, Dunedin, NEW ZEALAND.
http://xri.net/=nigel.stanger

> I suppose in the recent study cited in the article, it would be rather
> difficult to perform this kind of security breach on a MacBook Air,
> since the ram is not removable. Maybe that's a selling point for the
> MacBook Air?

The cold boot attack isn't something I generally tell people to worry
about. Sure, it's out there, but the odds of us being targeted by it
are low (unless you go to DefCon).

Here's an article I wrote about it on my security blog: http://securosis.com/2008/02/25/evaluating-and-protecting-yourself-from-the-cold-boot-encryption-attack/

Slightly more worrisome is Firewire- because firewire supports DMA
(direct memory access) you can, on almost any system, just plug into a
firewire port and read memory contents (this doesn't work on USB).

So yes- the Air is nearly impossible to exploit with EITHER a cold
boot attack or firewire/DMA attack :)

On 12/11/08 7:04 AM, "rmogull-tbtsecurosis.com" <rmogull-tbtsecurosis.com>
wrote:

> The cold boot attack isn't something I generally tell people to worry
> about. Sure, it's out there, but the odds of us being targeted by it
> are low (unless you go to DefCon).
>
> Here's an article I wrote about it on my security blog:
> http://securosis.com/2008/02/25/evaluating-and-protecting-yourself-from-the-co
> ld-boot-encryption-attack/
>
> Slightly more worrisome is Firewire- because firewire supports DMA
> (direct memory access) you can, on almost any system, just plug into a
> firewire port and read memory contents (this doesn't work on USB).

That was something I talked about at with some Apple people at the first
post-FW WWDC, after the FW session. I said that it seemed to me if someone
wanted, they could use a lot of solid-state RAM and FW to build a big 'ol
memory tap.

The Apple people were not real happy that I had thought that particular
thought.

--
John C. Welch

--On December 10, 2008 4:26:23 AM -0800 "LewisGmail" <gkremegmail.com>
wrote:

>> If you allow your computer to go into hibernation mode, the entire
>> contents
>> of memory is written to your hard drive,
>
> encrypted
>
> System Preferences -> Security -> General -> Use secure virtual memory

I'm not on a portable, just a mac mini but I enabled hibernate on it a
while ago. Going in and turning this on did not cause the sleepimage file
to be encrypted.

You can check your machine to see if hibernation is creating an encrypted
file by opening Terminal and doing:
pmset -g

This will display your power management settings. The hibernate mode
indicates the type of sleep that is enabled. A 5 or 7 means hibernation
uses secure virtual memory. Before and after turning on Use secure virtual
memory my hibernation mode was 1.

An explanation of the hibernate mode numbers is here:
<http://www.normalesup.org/~martinez/macosx/>

According to Apple's man page on pmset, 3 is the default for portables.
Again, not sure that is changed automatically if Use Secure Virtual Memory
is on.

None of this solves the problem of insecure temp files either.

--On December 10, 2008 4:26:23 AM -0800 Jeffrey McPheeters
<lifelonglearnermac.com> wrote:

>> into a computer and read out the contents. If you've written out
>> memory to
>> an unencrypted disk they have all the time in the world to scan what
>> was in
>> your computer's memory.
>>
>> <http://www.sciencedaily.com/releases/2008/02/080221105820.htm>
>
> I suppose in the recent study cited in the article, it would be rather
> difficult to perform this kind of security breach on a MacBook Air,
> since the ram is not removable. Maybe that's a selling point for the
> MacBook Air?

freeze the memory, swap the hard drive with your own (or boot from a usb
flash drive) that just dumps memory to a file. I don't believe the EFI boot
process wipes memory on boot.