Carlos Moreno wrote:
> I'm a little puzzled by this --- mostly when looking at the new
> Ubuntu *Server* 7.10, which includes a partitioning option that
> reads more or less "Guided -- set up LVM with encryption"
>
> The reason I'm puzzled is: what about key management?? I
> mean, a server is just embedded software that is supposed to
> run on a standalone basis; that would mean that whatever
> procedure necessary to decrypt all the data is part of the data
> and it has to be in clear (and work on its own).
>
> If we're talking a desktop/workstation, it makes sense to me
> that each user's data is encrypted with something that derives
> from the user's password, so that no-one would be able to do
> anything until the user supplies their password (of course,
> this is under the premises that the encryption algorithm is
> solid, and the user password uncrackable). In fact, for a
> notebook/portable setup, this seems to me like an essential
> feature, right?
>
> But I still don't see any significant advantage in encrypting
> something with a procedure that requires the data to self-
> decrypt --- if the attackers steal the data, they're stealing
> the password and the decryption procedure along with it, so
> where's the real benefit?
>
> Thanks for any comments,
>
> Carlos
> --
>

things like
sticking in a live-cd and doing a chroot /mnt/pc1hda1 /bin/bash
or copying all the data aren't as easy anymore

Carlos Moreno (07-11-07 04:54:09):

> I'm a little puzzled by this --- mostly when looking at the new Ubuntu
> *Server* 7.10, which includes a partitioning option that reads more or
> less "Guided -- set up LVM with encryption"
>
> The reason I'm puzzled is: what about key management?? I mean, a
> server is just embedded software that is supposed to run on a
> standalone basis; that would mean that whatever procedure necessary to
> decrypt all the data is part of the data and it has to be in clear
> (and work on its own).

Your thinking is not necessarily wrong. In the hypothetical ideal case
you can trust a server to run forever unattended, and it never fails or
has security holes. But reality is a totally different story. You are
going to access the server a lot, do administrative tasks, do system
updates, etc. One other situation where you certainly pay attention is
when restarting the server. This is where encryption comes in.

Since a server is assumed to run as long as possible, in the optimal
case, you'll do system restarts only when necessary. So you sit at your
terminal and watch the server boot up. Why shouldn't it additionally
ask for a filesystem password?

This can be a hazard, though, should your server ever restart
unintentionally (because of a kernel failure or something). Unattended
booting becomes impossible, because you're required to give the
password. But if such a thing happens, then you're going to look at the
server as soon as possible anyway.


> If we're talking a desktop/workstation, it makes sense to me that each
> user's data is encrypted with something that derives from the user's
> password, so that no-one would be able to do anything until the user
> supplies their password (of course, this is under the premises that
> the encryption algorithm is solid, and the user password uncrackable).
> In fact, for a notebook/portable setup, this seems to me like an
> essential feature, right?

If you care about your privacy, yes. Unfortunately most people don't.


> But I still don't see any significant advantage in encrypting
> something with a procedure that requires the data to self-decrypt ---
> if the attackers steal the data, they're stealing the password and the
> decryption procedure along with it, so where's the real benefit?

Self-decryption yes, self-initialization no. Consider the usual case,
where the server is located somewhere in a data center of a third-party
company. The server administrator doesn't have physical access to the
server, but the data center operators do. You wouldn't like them to
access your data, would you?

Though there is almost no way to prevent that, it drastically increases
the difficulty of accessing the data. They will need the encryption
password, which is only possible by trojaning the server's operating
system and waiting for you to supply it.

It's much better to encrypt and decrypt the sensitive information
off-site, such that the cleartext never enters the server, if this is
possible.


Regards,
Ertugrul Söylemez.


--
Security is the one concept, which makes things in your life stay as
they are. Otto is a man, who is afraid of changes in his life; so
naturally he does not employ security.

On Wed, 07 Nov 2007 04:54:09 -0800, Carlos Moreno wrote:


> The reason I'm puzzled is: what about key management?? I
> mean, a server is just embedded software that is supposed to
> run on a standalone basis; that would mean that whatever
> procedure necessary to decrypt all the data is part of the data
> and it has to be in clear (and work on its own).

Did you check out eCryptfs in the newer kernels? I've been using it awhile
and I like it, very transparent and stays out of the way while you work,
but without someone getting your RSA key and passphase, those files are
useless to them.

http://sourceforge.net/projects/ecryptfs/

/usr/src/linux-2.6.23.1/Documentation/filesystems/ecryptfs.txt


Unless I'm misunderstanding you...


--
[** America, the police state **]
Whoooose! What's that noise? Why, it's US citizen's
rights, going down the toilet with Bush flushing.
http://www.wired.com/politics/securi...007/08/wiretap
http://www.hermes-press.com/police_state.htm