linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* crypting filesystems
@ 2005-04-04 10:45 Andreas Hartmann
  2005-04-04 20:51 ` Wiktor
  0 siblings, 1 reply; 3+ messages in thread
From: Andreas Hartmann @ 2005-04-04 10:45 UTC (permalink / raw)
  To: linux-kernel

Hello,

I want to crypt some filesystems (/var, /home, /Data). I'm running LVM I
on all these partitions yet.

I searched, how to do this with linux and found 3 ways to achieve, what I
want to do.

1. crypto-loop (with kernel 2.6)
2. loop-AES (with kernel 2.2.x, 2.4.x and 2.6.x)
3. dm-crypt (with kernel 2.6.x)

Because I'm new to filesystem encryption, I searched for documentation of
all of these solutions and found, that crypto-loop seems not to be
maintained any more. loop-AES and dm-crypt remained. dm-crypt uses the
device mapper concept, which I know long ago from LVM and which therefore
seems to be the most logical solution to me. There is no need to patch the
mount-utility and integration is "out of the box".

So, I suggested to use dm-crypt with 2.6.11.6. I built 3 partitions with
cryptsetup (LUKS) with ESSIV-cipher and 256Bit keys on top of LVM 1 and
reiserfs as filesystem. The swap-partition is crypted with a random key,
which is generated each time at booting.

After all, there are remaining some questions open concerning the security
 / stability of this solution.

1. In order to put in the passphrase just once a time at booting, I put
the passphrase in a gpg-crypted file (cipher AES256 and 256Bit key size),
which is decrypted at boot-time to /tmp (-> tmpfs) and immediately removed
with shred, after activating the three partitions. Is it possible to see
the cleartext password after this action in tmpfs?

2. Is it possible to gain the passphrase from the active encrypted
partitions (because the passphrase is somewhere held in the RAM)?

3. I read at clemens.endorphin.org about 4 different cipher modes (CBC,
CMC, EME and LRW). Actually implemented in dm-crypt is the public-IV
on-disk format or ESSIV, both using CBC cipher mode. The other cipher
modes (CMC, EWE, LRW) are not implemented yet although they promise more
security.

My question is:
Was anybody able to decrypt one of these two implemented public-IV on-disk
formats, or, to say it in other words: are the known problems a mainly
theoretical discussion until today?

4. Are there any master keys existing, which could be used to open every
encrypted filesystem?

5. I read about problems (corrupted filesystem) with reiserfs (I'm using V
3.6). Are they fixed in 2.6.11.6? Would it be better to use XFS?



I would be very glad, if somebody could give me some advice.


Kind regards,
Andreas Hartmann

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: crypting filesystems
  2005-04-04 10:45 crypting filesystems Andreas Hartmann
@ 2005-04-04 20:51 ` Wiktor
  2005-04-05 13:43   ` Felipe Alfaro Solana
  0 siblings, 1 reply; 3+ messages in thread
From: Wiktor @ 2005-04-04 20:51 UTC (permalink / raw)
  To: Andreas Hartmann; +Cc: linux-kernel

Hi,

I'm using the following method and it seems to be working fine 
(involving crypto-loop):

i have normal ext3 /boot partition, where i store kernel image & initrd. 
after lilo boots the kernel, initrd sets up /dev/loop0 to be 
crypto-loop/blowfish for /dev/hda1 (losetup /dev/loop0 /dev/hda1 -e 
blowfish). losetup asks for passphrase, and (if entered correctly), 
/dev/loop0 is mounted as root filesystem (it can be done also by simple 
mount call: mount /dev/hda1 /some-place -o rw,encryption=blowfish). for 
encrypting more filesystems with one passphrase, you can read it in 
shell script in non-echo-mode (if such exists, i'm not sure), and pass 
it to mount or losetup. crypto-loop makes possible to switch encryption 
type without modifying whole initrd.

Regarding your questions:

 > 1. In order to put in the passphrase just once a time at booting, I 
put the passphrase in a gpg-crypted file (cipher AES256 and 256Bit key 
size), which is decrypted at boot-time to /tmp (-> tmpfs) and 
immediately removed with shred, after activating the three partitions. 
Is it possible to see the cleartext password after this action in tmpfs?

Disk encryption usually protects from hardware-attacks (when hacker has 
physical access to the hardware). if you keep passphrase 
reversible-encrypted, attacker can read it and run brute-force attack 
using some huge-computing-capacity. is this what you want?

 > 2. Is it possible to gain the passphrase from the active encrypted 
partitions (because the passphrase is somewhere held in the RAM)?

Only when attacker has root privileges. But i'm not sure if it is 
possible to extract passphrase knowing both encrypted and not encrypted 
data. What i mean is that usually each filesystem begins with 
filesystem-specyfic-header, which is constant or similar to each other. 
so, if attacker has encrypted form of this header and can estimate 
unencryptes form, it can possibly gain the passphrase. (but therse are 
only my ideas, i don't know how the encryptino-algorithm works).

 > 4. Are there any master keys existing, which could be used to open 
every encrypted filesystem?

We all wish they are no such 'features'.

--
wixor
May the Source be with you.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: crypting filesystems
  2005-04-04 20:51 ` Wiktor
@ 2005-04-05 13:43   ` Felipe Alfaro Solana
  0 siblings, 0 replies; 3+ messages in thread
From: Felipe Alfaro Solana @ 2005-04-05 13:43 UTC (permalink / raw)
  To: Wiktor; +Cc: Andreas Hartmann, linux-kernel

On Apr 4, 2005 9:51 PM, Wiktor <victorjan@poczta.onet.pl> wrote:
> Hi,
> 
> I'm using the following method and it seems to be working fine
> (involving crypto-loop):
> 
> i have normal ext3 /boot partition, where i store kernel image & initrd.
> after lilo boots the kernel, initrd sets up /dev/loop0 to be
> crypto-loop/blowfish for /dev/hda1 (losetup /dev/loop0 /dev/hda1 -e
> blowfish). losetup asks for passphrase, and (if entered correctly),
> /dev/loop0 is mounted as root filesystem (it can be done also by simple
> mount call: mount /dev/hda1 /some-place -o rw,encryption=blowfish). for
> encrypting more filesystems with one passphrase, you can read it in
> shell script in non-echo-mode (if such exists, i'm not sure), and pass
> it to mount or losetup. crypto-loop makes possible to switch encryption
> type without modifying whole initrd.
> 
> Regarding your questions:
> 
>  > 1. In order to put in the passphrase just once a time at booting, I
> put the passphrase in a gpg-crypted file (cipher AES256 and 256Bit key
> size), which is decrypted at boot-time to /tmp (-> tmpfs) and
> immediately removed with shred, after activating the three partitions.
> Is it possible to see the cleartext password after this action in tmpfs?
> 
> Disk encryption usually protects from hardware-attacks (when hacker has
> physical access to the hardware). if you keep passphrase
> reversible-encrypted, attacker can read it and run brute-force attack
> using some huge-computing-capacity. is this what you want?
> 
>  > 2. Is it possible to gain the passphrase from the active encrypted
> partitions (because the passphrase is somewhere held in the RAM)?
> 
> Only when attacker has root privileges. But i'm not sure if it is
> possible to extract passphrase knowing both encrypted and not encrypted
> data. What i mean is that usually each filesystem begins with
> filesystem-specyfic-header, which is constant or similar to each other.
> so, if attacker has encrypted form of this header and can estimate
> unencryptes form, it can possibly gain the passphrase. (but therse are
> only my ideas, i don't know how the encryptino-algorithm works).

What´s kept in RAM is the AES key used to decrypt disk blocks.
However, the passphrase from which the AES key is derived (usually by
using a hash function) is not kept in memory.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-04-05 13:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-04-04 10:45 crypting filesystems Andreas Hartmann
2005-04-04 20:51 ` Wiktor
2005-04-05 13:43   ` Felipe Alfaro Solana

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).