Encrypted containers

Hello,


I previously posted this on a different newsgroup and got no reply.
thought I would try my luck here.

I want to implement some type of security measure for the sensitive data
on my computer.

During my research, I came across an article on encrypted containers in
link below and decided this looked like a good technique for me to
implement. The key is stored on a USB drive and the file encrypt and
decrypt on the fly.

The article is located at: http://www.linuxjournal.com/article/8599


I am running:

KDE 3.4 PowerPack
Mandriva 2006 X_64 PowerPack
Linux 2.6.12-12mdksmp
x86_64 AMD Athlon(tm) 64 Processor 3000+



Any advice about this encryption technique / protecting my info in this
manner before I start down this path is greatly appreciated.

Best regards,

Dave

DaveM <dave@no.att.net> (06-05-28 21:58:35):

> I previously posted this on a different newsgroup and got no reply.
> thought I would try my luck here.

You are right here. =)


> I want to implement some type of security measure for the sensitive
> data on my computer.
>
> During my research, I came across an article on encrypted containers
> in link below and decided this looked like a good technique for me to
> implement. The key is stored on a USB drive and the file encrypt and
> decrypt on the fly.
>
> The article is located at: http://www.linuxjournal.com/article/8599
>
> [...]
>
> Any advice about this encryption technique / protecting my info in
> this manner before I start down this path is greatly appreciated.


With encrypted 'container' the author means normal dm-crypted
filesystems. The idea is to mount the appropriate filesystem when
logging in.

However, there are a few problems with his system. The keys are being
retrieved from a USB device, which needs to be plugged in, when logging
in. What happens, when you lose your USB device? Then your data is
effectively lost as well. You might consider to have a backup of your
key, but that totally eliminates the security of the whole system (like
writing your password on a piece of paper and placing it under your
keyboard).

As far as I can see, he is using a single key and a single filesystem,
and he is mixing the weaker cryptoloop with the stronger dm-crypt.
Remember that a chain is only as strong as its weakest link. This is
especially true for cryptosystems. Next, this is equivalent to just
using dm-crypt and mounting the appropriate device on boot.

Moreover, there is an obvious weakness in his system, namely those USB
storage devices. If one gets stolen, then the entire system may be
compromised, and become only as secure as a totally unencrypted system.

Not to criticize destructively, but the author doesn't seem to have much
of a clue about his own system. There are special configuration files
for loading kernel modules on boot. He is doing that via boot scripts,
which shouldn't be done. The designers of a distribution will have some
good reason to provide extra configuration files for that purpose.

Now to the interesting part. Actually, that guy is reinventing the
wheel. Using PAM (pluggable authentication modules) is the better
approach. Every user should need a secure password to log in (which I'm
assuming here). Why not use that password for filesystem encryption,
too, on a per-user basis? That way, the data is not only protected from
foreign attackers, but even from internal attackers (no two users should
use the same password anyway), and their security does not depend on
where you place your USB devices at home.

You can further strengthen that system by additionally using a key
stored on a USB device. But then consider that your data may be lost,
when you lose that device. However, unlike the system above, in this
case, the data really is just lost, not compromised, because an attacker
still doesn't know the password.

PAM are used in almost any desktop and server distribution (including
Mandriva). They are used to authenticate users, but they can do more
when told to. You'll want to create one encrypted filesystem for each
user and mount it, as the user logs in, and unmount it, as they log out.
PAM then uses the user's password (which isn't stored anywhere) as the
key for the particular filesystem. You will find lots of HOWTOs and
tutorials on how to do that. It's easy -- far easier than the method
above.


Regards,
E.S.

On 29.05.2006, Ertugrul Soeylemez <never@drwxr-xr-x.org> wrote:
> Not to criticize destructively, but the author doesn't seem to have much
> of a clue about his own system. There are special configuration files
> for loading kernel modules on boot. He is doing that via boot scripts,
> which shouldn't be done. The designers of a distribution will have some
> good reason to provide extra configuration files for that purpose.
>
> Now to the interesting part. Actually, that guy is reinventing the
> wheel. Using PAM (pluggable authentication modules) is the better
> approach. Every user should need a secure password to log in (which I'm
> assuming here). Why not use that password for filesystem encryption,
> too, on a per-user basis? That way, the data is not only protected from
> foreign attackers, but even from internal attackers (no two users should
> use the same password anyway), and their security does not depend on
> where you place your USB devices at home.

I was thinking about something similar, Loop-AES based. I think that
using password from /etc/passwd to encrypt _whole filesystem_ is a bad
idea. Consider user who wants to change his password. But it's quite
easy to fix this problem: encrypt with password just an encryption key.
It's easy to decrypt that key and encrypt it back using new password,
when changing passwords.

The problem is strength of user's password.

> PAM are used in almost any desktop and server distribution (including
> Mandriva).

Show me one distribution, for which PAM package isn't accessible.
Slackware doesn't count because of Extended Slackware
http://xslack.zsh.bash.org.pl/?lang=en

> They are used to authenticate users, but they can do more
> when told to. You'll want to create one encrypted filesystem for each
> user and mount it, as the user logs in, and unmount it, as they log out.

Just to say my thoughts loud (I'm planning writing such a module):
how should multiple logins be handled? Probably some kind of counter
(GDBM database?) for each logged user, cleaned up on reboot. And there
should be additional directory with encrypted keys to filesystem.

--
Feel free to correct my English
Stanislaw Klekot

Ertugrul Soeylemez wrote:
> DaveM <dave@no.att.net> (06-05-28 21:58:35):
>
>> I previously posted this on a different newsgroup and got no reply.
>> thought I would try my luck here.
>
> You are right here. =)
>
>
>> I want to implement some type of security measure for the sensitive
>> data on my computer.
>>
>> During my research, I came across an article on encrypted containers
>> in link below and decided this looked like a good technique for me to
>> implement. The key is stored on a USB drive and the file encrypt and
>> decrypt on the fly.
>>
>> The article is located at: http://www.linuxjournal.com/article/8599
>>
>> [...]
>>
>> Any advice about this encryption technique / protecting my info in
>> this manner before I start down this path is greatly appreciated.
>
>
> With encrypted 'container' the author means normal dm-crypted
> filesystems. The idea is to mount the appropriate filesystem when
> logging in.
>
> However, there are a few problems with his system. The keys are being
> retrieved from a USB device, which needs to be plugged in, when logging
> in. What happens, when you lose your USB device? Then your data is
> effectively lost as well. You might consider to have a backup of your
> key, but that totally eliminates the security of the whole system (like
> writing your password on a piece of paper and placing it under your
> keyboard).
>
> As far as I can see, he is using a single key and a single filesystem,
> and he is mixing the weaker cryptoloop with the stronger dm-crypt.
> Remember that a chain is only as strong as its weakest link. This is
> especially true for cryptosystems. Next, this is equivalent to just
> using dm-crypt and mounting the appropriate device on boot.
>
> Moreover, there is an obvious weakness in his system, namely those USB
> storage devices. If one gets stolen, then the entire system may be
> compromised, and become only as secure as a totally unencrypted system.
>
> Not to criticize destructively, but the author doesn't seem to have much
> of a clue about his own system. There are special configuration files
> for loading kernel modules on boot. He is doing that via boot scripts,
> which shouldn't be done. The designers of a distribution will have some
> good reason to provide extra configuration files for that purpose.
>
> Now to the interesting part. Actually, that guy is reinventing the
> wheel. Using PAM (pluggable authentication modules) is the better
> approach. Every user should need a secure password to log in (which I'm
> assuming here). Why not use that password for filesystem encryption,
> too, on a per-user basis? That way, the data is not only protected from
> foreign attackers, but even from internal attackers (no two users should
> use the same password anyway), and their security does not depend on
> where you place your USB devices at home.
>
> You can further strengthen that system by additionally using a key
> stored on a USB device. But then consider that your data may be lost,
> when you lose that device. However, unlike the system above, in this
> case, the data really is just lost, not compromised, because an attacker
> still doesn't know the password.
>
> PAM are used in almost any desktop and server distribution (including
> Mandriva). They are used to authenticate users, but they can do more
> when told to. You'll want to create one encrypted filesystem for each
> user and mount it, as the user logs in, and unmount it, as they log out.
> PAM then uses the user's password (which isn't stored anywhere) as the
> key for the particular filesystem. You will find lots of HOWTOs and
> tutorials on how to do that. It's easy -- far easier than the method
> above.
>
>
> Regards,
> E.S.
Thanks for the advice. I still have some research to do :)

R/
Dave

"Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> (06-05-29 14:23:14):

> > Now to the interesting part. Actually, that guy is reinventing the
> > wheel. Using PAM (pluggable authentication modules) is the better
> > approach. Every user should need a secure password to log in (which
> > I'm assuming here). Why not use that password for filesystem
> > encryption, too, on a per-user basis? That way, the data is not
> > only protected from foreign attackers, but even from internal
> > attackers (no two users should use the same password anyway), and
> > their security does not depend on where you place your USB devices
> > at home.
>
> I was thinking about something similar, Loop-AES based. I think that
> using password from /etc/passwd to encrypt _whole filesystem_ is a bad
> idea. Consider user who wants to change his password. But it's quite
> easy to fix this problem: encrypt with password just an encryption
> key. It's easy to decrypt that key and encrypt it back using new
> password, when changing passwords.

Yes, and that idea has already been made code of, but not on a per-user
basis. See LUKS.


> The problem is strength of user's password.

Yes, but that's not the developer's responsibility. Other people should
care about that.


> > They are used to authenticate users, but they can do more when told
> > to. You'll want to create one encrypted filesystem for each user
> > and mount it, as the user logs in, and unmount it, as they log out.
>
> Just to say my thoughts loud (I'm planning writing such a module):
> how should multiple logins be handled? Probably some kind of counter
> (GDBM database?) for each logged user, cleaned up on reboot. And there
> should be additional directory with encrypted keys to filesystem.

That can be as easy as "do not unmount, until the user is logged out
everywhere". Those counters are already there, you just need to use
them. There is no point in writing your own, possibly buggy counters.
The keys can be stored on the filesystems themselves (encrypted with the
user's password, of course). Maybe as a filesystem prefix, like in
LUKS. You may even want to use LUKS (which is only a specification) as
a base to start with. That would save you some development work.


Regards,
E.S.

On 31.05.2006, Ertugrul Soeylemez <never@drwxr-xr-x.org> wrote:
> "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> (06-05-29 14:23:14):
>
>> > Now to the interesting part. Actually, that guy is reinventing the
>> > wheel. Using PAM (pluggable authentication modules) is the better
>> > approach. Every user should need a secure password to log in (which
>> > I'm assuming here). Why not use that password for filesystem
>> > encryption, too, on a per-user basis? That way, the data is not
>> > only protected from foreign attackers, but even from internal
>> > attackers (no two users should use the same password anyway), and
>> > their security does not depend on where you place your USB devices
>> > at home.
>>
>> I was thinking about something similar, Loop-AES based. I think that
>> using password from /etc/passwd to encrypt _whole filesystem_ is a bad
>> idea. Consider user who wants to change his password. But it's quite
>> easy to fix this problem: encrypt with password just an encryption
>> key. It's easy to decrypt that key and encrypt it back using new
>> password, when changing passwords.
>
> Yes, and that idea has already been made code of, but not on a per-user
> basis. See LUKS.

I don't like LUKS. It's written by the same people as device mapper. I'd
rather use Loop-AES.

>> The problem is strength of user's password.
>
> Yes, but that's not the developer's responsibility. Other people should
> care about that.

But it should be pointed out. Near cryptography there are some obvious
things which, if comes to end user, are not so obvious.

>> > They are used to authenticate users, but they can do more when told
>> > to. You'll want to create one encrypted filesystem for each user
>> > and mount it, as the user logs in, and unmount it, as they log out.
>>
>> Just to say my thoughts loud (I'm planning writing such a module):
>> how should multiple logins be handled? Probably some kind of counter
>> (GDBM database?) for each logged user, cleaned up on reboot. And there
>> should be additional directory with encrypted keys to filesystem.
>
> That can be as easy as "do not unmount, until the user is logged out
> everywhere". Those counters are already there, you just need to use
> them.

You mean where? wtmp? It's not updated when you execute non-login shell
via ssh ("ssh yourhost bash -i") and can display logged users when
they're not logged. Do you have better place? Indeed, it would save me
some work.

> There is no point in writing your own, possibly buggy counters.
> The keys can be stored on the filesystems themselves (encrypted with the
> user's password, of course).

Do I understand you correctly? You want to store keys for encryption on
an encrypted filesystem?

> Maybe as a filesystem prefix, like in
> LUKS. You may even want to use LUKS (which is only a specification) as
> a base to start with. That would save you some development work.

--
Feel free to correct my English
Stanislaw Klekot

"Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> (06-05-31 17:53:10):

> I don't like LUKS. It's written by the same people as device
> mapper. I'd rather use Loop-AES.

I don't like it either, and I don't use it. But I do use dm-crypt,
because it's more suitable in my case. I use both AES (for my
filesystem) and Blowfish (for swap, because it's faster). As far as I
know, Loop-AES does only support AES.


> > > The problem is strength of user's password.
> >
> > Yes, but that's not the developer's responsibility. Other people
> > should care about that.
>
> But it should be pointed out. Near cryptography there are some obvious
> things which, if comes to end user, are not so obvious.

I didn't mean the users themselves. Other people like documentation
writers or frontend designers should do that. On the other hand, the
developer should make sure that their software cannot be used in a wrong
way.


> > > Just to say my thoughts loud (I'm planning writing such a module):
> > > how should multiple logins be handled? Probably some kind of
> > > counter (GDBM database?) for each logged user, cleaned up on
> > > reboot. And there should be additional directory with encrypted
> > > keys to filesystem.
> >
> > That can be as easy as "do not unmount, until the user is logged out
> > everywhere". Those counters are already there, you just need to use
> > them.
>
> You mean where? wtmp? It's not updated when you execute non-login shell
> via ssh ("ssh yourhost bash -i") and can display logged users when
> they're not logged. Do you have better place? Indeed, it would save me
> some work.

Well, I would just look if there is any process running under the
particular username. That should cover every case. You also could let
the user handle this via callback-like shell-scripts, and provide some
example scripts for basic configurations.


> > There is no point in writing your own, possibly buggy counters. The
> > keys can be stored on the filesystems themselves (encrypted with the
> > user's password, of course).
>
> Do I understand you correctly? You want to store keys for encryption
> on an encrypted filesystem?

Yes. Generate a hash of the user's password, XOR it with the actual key
and save the result. Or encrypt the key with the user's password, but
that would be essentially equivalent in terms of security (as long as
the output of the hash function is as large as the key).

Saving the key elsewhere would actually be security by obscurity. But
you may provide that as an option.


Regards,
E.S.

On 31.05.2006, Ertugrul Soeylemez <never@drwxr-xr-x.org> wrote:
> "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> (06-05-31 17:53:10):
>> > > Just to say my thoughts loud (I'm planning writing such a module):
>> > > how should multiple logins be handled? Probably some kind of
>> > > counter (GDBM database?) for each logged user, cleaned up on
>> > > reboot. And there should be additional directory with encrypted
>> > > keys to filesystem.
>> >
>> > That can be as easy as "do not unmount, until the user is logged out
>> > everywhere". Those counters are already there, you just need to use
>> > them.
>>
>> You mean where? wtmp? It's not updated when you execute non-login shell
>> via ssh ("ssh yourhost bash -i") and can display logged users when
>> they're not logged. Do you have better place? Indeed, it would save me
>> some work.
>
> Well, I would just look if there is any process running under the
> particular username. That should cover every case.

How about computational program running for few days under /tmp or
/mnt/results/ (unencrypted)? I know, I'm grumbling. But small GDBM
database would be simpler and, I think, more reliable than manual
grepping through /proc/.

> You also could let
> the user handle this via callback-like shell-scripts, and provide some
> example scripts for basic configurations.

That's good idea, but again, a bit more complex than counting users on
my own (remember that we're talking about mounted-by-root-user's-$HOME,
so user can't do simple `umount $HOME').

Anyway, thanks for ideas.

>> > There is no point in writing your own, possibly buggy counters. The
>> > keys can be stored on the filesystems themselves (encrypted with the
>> > user's password, of course).
>>
>> Do I understand you correctly? You want to store keys for encryption
>> on an encrypted filesystem?
>
> Yes. Generate a hash of the user's password, XOR it with the actual key
> and save the result. Or encrypt the key with the user's password, but
> that would be essentially equivalent in terms of security (as long as
> the output of the hash function is as large as the key).
>
> Saving the key elsewhere would actually be security by obscurity.

Heh, I see the point. I thought about storing the key for FS encryption,
but storing it encrypted with user's password, not as plain text. Let me
quote myself (<slrne7m1hd.fsq.dozzie@hans.zsh.bash.org.pl>):

| But it's quite
| easy to fix this problem: encrypt with password just an encryption key.
| It's easy to decrypt that key and encrypt it back using new password,
| when changing passwords.

--
Feel free to correct my English
Stanislaw Klekot

"Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> (06-05-31 20:43:24):

> > Well, I would just look if there is any process running under the
> > particular username. That should cover every case.
>
> How about computational program running for few days under /tmp or
> /mnt/results/ (unencrypted)? I know, I'm grumbling. But small GDBM
> database would be simpler and, I think, more reliable than manual
> grepping through /proc/.

You may also periodically look for whether there are still processes
running with a current workdir below the encrypted mountpoints, or
whether files are open there. That's easy to do. Remember that your
GDBM counters could not handle the case, where a user fully logs out,
but still has background jobs running. And also think about cronjobs
and the like. By the way, using a full blown database for that purpose
is overkill, IMO.


> > You also could let the user handle this via callback-like
> > shell-scripts, and provide some example scripts for basic
> > configurations.
>
> That's good idea, but again, a bit more complex than counting users on
> my own (remember that we're talking about
> mounted-by-root-user's-$HOME, so user can't do simple `umount $HOME').

As stated above, counting users has a few considerable flaws.


> >> Do I understand you correctly? You want to store keys for
> >> encryption on an encrypted filesystem?
> >
> > Yes. Generate a hash of the user's password, XOR it with the actual
> > key and save the result. Or encrypt the key with the user's
> > password, but that would be essentially equivalent in terms of
> > security (as long as the output of the hash function is as large as
> > the key).
> >
> > Saving the key elsewhere would actually be security by obscurity.
>
> Heh, I see the point. I thought about storing the key for FS
> encryption, but storing it encrypted with user's password, not as
> plain text. Let me quote myself
> (<slrne7m1hd.fsq.dozzie@hans.zsh.bash.org.pl>):
>
> | But it's quite easy to fix this problem: encrypt with password just
> | an encryption key. It's easy to decrypt that key and encrypt it
> | back using new password, when changing passwords.

Yes, but you can safely use a simple XOR cipher in this case. For a key
of K bits, choose a hash function with H bits, where H >= K. Generate
the hash value of the password with some fixed characters appended. If
H > K, split the hash into blocks of size K and XOR them all together.
Then finally XOR that final hash value with the key.

That's perfectly secure. Let me prove this. Let Q be the original
password. Append a few random, but fixed characters to get P. Those
characters don't need to be secret. Then let h be a hash function. K
is the filesystem encryption key, and C is the encrypted version of it.
So:

H(P) + K = C

The attacker does not know the password Q, but he might know H(Q),
because it may be listed in /etc/passwd or /etc/shadow (depending on
which hash function is in use there). So we append a few characters to
Q and call the result P. Then we calculate H(P). The attacker cannot
reconstruct this, not even by knowing H(Q). He would need to know Q
itself. So in the end, the attacker does not know H(P), because he does
not know P. He also does not know K, the encryption key. So all he
knows is C, which leaves two variables in the equation above.
Unfortunately for the attacker, he cannot place any constraints about
H(P) and K, because both can be arbitrary.

To get the key K from C, just recompute H(P) (which you can do, when the
user logs in) and XOR it with C again.


Regards,
E.S.

On 01.06.2006, Ertugrul Soeylemez <never@drwxr-xr-x.org> wrote:
> "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> (06-05-31 20:43:24):
>
>> > Well, I would just look if there is any process running under the
>> > particular username. That should cover every case.
>>
>> How about computational program running for few days under /tmp or
>> /mnt/results/ (unencrypted)? I know, I'm grumbling. But small GDBM
>> database would be simpler and, I think, more reliable than manual
>> grepping through /proc/.
>
> You may also periodically look for whether there are still processes
> running with a current workdir below the encrypted mountpoints, or
> whether files are open there. That's easy to do. Remember that your
> GDBM counters could not handle the case, where a user fully logs out,
> but still has background jobs running. And also think about cronjobs
> and the like.

Right. And that's why I thought loudly :) Thanks again.

> By the way, using a full blown database for that purpose
> is overkill, IMO.

GDBM (not Berkeley DB) is very simple database engine. And it's easier
in use than flat files, I think.

>> >> Do I understand you correctly? You want to store keys for
>> >> encryption on an encrypted filesystem?
>> >
>> > Yes. Generate a hash of the user's password, XOR it with the actual
>> > key and save the result. Or encrypt the key with the user's
>> > password, but that would be essentially equivalent in terms of
>> > security (as long as the output of the hash function is as large as
>> > the key).
>> >
>> > Saving the key elsewhere would actually be security by obscurity.
>>
>> Heh, I see the point. I thought about storing the key for FS
>> encryption, but storing it encrypted with user's password, not as
>> plain text. Let me quote myself
>> (<slrne7m1hd.fsq.dozzie@hans.zsh.bash.org.pl>):
>>
>> | But it's quite easy to fix this problem: encrypt with password just
>> | an encryption key. It's easy to decrypt that key and encrypt it
>> | back using new password, when changing passwords.
>
> Yes, but you can safely use a simple XOR cipher in this case.

Yes. It's encryption, too. Simpler than I initially had in mind, but
still encryption.

--
Feel free to correct my English
Stanislaw Klekot