

Disk Encryption by Default in Chrome OS - panarky
http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data

======
trotsky
IMO the way they did verified boot is even better. TPM style hardware assisted
boot chain verification all the way down to a rolling full root filesystem
hash list.

Sounds like a smartphone sure, except that it doesn't prevent running unsigned
code it just detects tampering with standard executables. And it'll let you
tamper all you want, it just warns you that they failed and allow you to
choose to reload from a known good if you'd like.

Not that disk encryption isn't important, just that I'd bet 99% of data theft
isn't local to the machine.

Nice to see a security implementation that is dealing with the current threat
level (ie, fucked) but not using it as an excuse to lock out modification

[http://www.chromium.org/chromium-os/chromiumos-design-
docs/v...](http://www.chromium.org/chromium-os/chromiumos-design-
docs/verified-boot)

~~~
SpikeGronim
Agreed, finally a use for TPM that isn't customer hostile.

------
cosgroveb
I noticed that they are using cperciva's scrypt() for key strengthening:

<http://www.tarsnap.com/scrypt.html>

They opted to go with a memory bound approach rather than a CPU bound approach
so that login time doesn't adversely affect UX.

~~~
tedunangst
Yes, the "Managing encryption keys" section was the most interesting part. I
was wondering how they were going to protect the disk encryption key.

I'm not positive that a pure memory based key strengthening is all the useful
though. Depends on how much time they think is too much to login, but
considering the class of machine, I'd be worried if they aimed lower than one
second.

------
MikeCapone
That's great. All portable devices should come with robust encryption that is
easy to enable (or that is turned on by default).

More and more people are carrying more and more of their life around in
digital form. It shouldn't be left unencrypted.

~~~
lkjhgfvhjk
And you trust Google with the keys?

~~~
jrockway
Google is not the average person's enemy. If you are cheating on your wife,
you don't want her to be able to open up your netbook and read all your emails
about it. But if Google knows, it really doesn't matter -- Google is not your
wife. Google could care less who you are sleeping with.

~~~
natch
We actually don't know what Google cares about, nor do we (including you) know
what Future Google cares about.

But your point is moot, because whether Google cares or not is irrelevant, if
someone else gets a subpoena and Google hands out the keys and the data, which
is conveniently backed up in the cloud.

------
there
looks like it's basically the same setup as mac os' filevault where each user
has an encrypted, auto-expanding disk image that sits atop a normal
filesystem.

~~~
kgo
Except on mac your data can leak into tmp or swap.

I was going to go on a rant about how encrypting home directories is
practically pointless, and you really need full disk encryption if you're
worried about people snooping, but was glad to see that the developers know
where your info can leak...

~~~
scrod
> _Except on mac your data can leak into tmp or swap._

Only if you let it:
[http://docs.info.apple.com/article.html?path=Mac/10.6/en/118...](http://docs.info.apple.com/article.html?path=Mac/10.6/en/11852.html)

~~~
kgo
I would word that as "Only if you don't explicitly disable it". Not trying to
be super-pedantic, but I think it's important to note that the default is
unencrypted, since most people probably won't change that default, especially
when the feature isn't mentioned on the FileVault doc page.

But yeah, flip that switch if you're running OSX.

EDIT: Acutally looks like that is the default on Snow Leopard. Disregard this
comment.

