[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-crypto
Subject:    Re: Vulnerability in encrypted loop device for Linux
From:       Gisle S{lensminde <gisle () ii ! uib ! no>
Date:       2001-12-19 14:09:05
[Download RAW message or body]

On Wed, 19 Dec 2001, Jerome Etienne wrote:

> On Wed, Dec 19, 2001 at 11:51:43AM +0100, Gisle S{lensminde wrote:
> > Yes, this is a problem with loopback crypto. The problem is that the
> > loopback interface assume that it's length preserving,
>
> can you explain the rationnal behind such assumption ?

My impression about the loopback interface, is that it is supposed to
be a 1:1 mapping fom the raw disk to the loopback. The traditional
use of the loopback interface (without encryption) have been used for
such things as mounting cd images without burning it to a CD.
Filesystems and other usages of disk partition may assume things
about the underlaying media. It shoudn't but before I know that
I'm a bit skeptical to breaking the 1:1 relationship present in
the loopback interface. That's the reason for stating that I don't
know too much about the block device part of the kernel. I tried
to discuss potential problems. I Not having a block size divisible by
512 can make problems for many file systems, so the MAC should not
be stored at the end of each block anyway.

A block cluster approch would be preferable, since that don't require
scanning the disk on every mount/unmount. What about a block containing
a 128 bit HMAC-SHA1 of the preceding.

Anyway - I would prefere an encrypted filesystem rather than the loopback
device.

> > and that make
> > insertion of a MAC difficult. Calculating a MAC at mount/unmount will
> > except taking long time, also fail to differ between tampering and
> > a power failure. This may make the MAC useless in a security perspective.
>
> i disagree. as a user, i may know if my computer uncleanly umount
> a partition (e.g. i was in front of it when it crashed).
> so when i reboot it, i know it was a unclean mount and not a attack.

My experience is that users don't know this, and that it should be taken
into account when making cryptosystems.

<note sniped>
> i dont understand your note
>

Maybe not well explained but it means that a tail of the disk block
(the i last bytes, possibly the whole block) of a modified disk block can
be replaced by the ciphertext from before the modification, and unlike
your attack there will be no blocks of random garbage in this case.

I can try to expalin it better, but that will take some more time.

--
Gisle Sælensminde ( gisle@ii.uib.no )

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. (from RFC 1925)



-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

[prev in list] [next in list] [prev in thread] [next in thread]