|
Home > Archive > Debian Security > June 2005 > safety of encrypted filesystems
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
safety of encrypted filesystems
|
|
| martin f krafft 2005-06-17, 2:53 am |
| Encrypted filesystems are hip these days, and that's good. One of
the reasons why I have not jumped on the waggon is a concern about
their safety.
When using a block cipher such as AES or similar to encode e.g.
a file of 1024 Mb, the blocks of the ciphertext are in relation to
each other. This is accomplished using methods like CBC (Cipher
Block Chaining, among others). The motivation here is to fend off
statistical (and replay) attacks.
Storage media these days are usually okay, but there have been times
when a bad block on a disk, or a corrupt byte on a flash medium have
caused trash to be returned for the block. Please correct me if I am
wrong, but with a single file spanning 1 Gb of medium, chances are
fairly high for such a bad block to happen within the file (given
that it happens at all).
If such a bad block occurs and renders a small part of the encrypted
file unreadable, wouldn't the entire partition and all its data be
effectively destroyed?
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
"ah, but a man's reach should exceed his grasp,
or what's a heaven for?"
-- robert browning
| |
| Florian Weimer 2005-06-17, 2:53 am |
| * martin f. krafft:
> Encrypted filesystems are hip these days, [...]
Are they? I thought most of the fuzz was about encrypted block
devices.
> If such a bad block occurs and renders a small part of the encrypted
> file unreadable, wouldn't the entire partition and all its data be
> effectively destroyed?
A corrupt sector corrupts the remaining part of the block. Block
sizes are much smaller than 1 GB because when part of a block is
changed, all the following bytes have to be rewritten (if a reasonable
the cipher mode is used).
By the way, the very fact that the block is not lost completely
indicates a major cryptographic weakness: there are no integrity
checks at all. (The constant IV problem is another one.) These
weaknesses don't matter in many scenarios, but it's still an
undesirable situation.
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2005-06-17, 2:53 am |
| also sprach Florian Weimer <fw@deneb.enyo.de> [2005.06.17.0834 +0200]:
>
> Are they? I thought most of the fuzz was about encrypted block
> devices.
That's what I mean.
>
> A corrupt sector corrupts the remaining part of the block. Block
> sizes are much smaller than 1 GB because when part of a block is
> changed, all the following bytes have to be rewritten (if a reasonable
> the cipher mode is used).
Of course blocks are small, e.g. 64 bytes. However, doesn't CBC or
EBC make sure that every block is chained to its predecessor, making
even the very last block of a file dependent on the bits of the very
first block?
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
DISCLAIMER: this entire message is privileged communication, intended
for the sole use of its recipients only. If you read it even though
you know you aren't supposed to, you're a poopy-head.
| |
| Florian Weimer 2005-06-17, 2:53 am |
| * martin f. krafft:
>
> Of course blocks are small, e.g. 64 bytes.
These are *cipher* blocks, and they are chained only within a *block
device* block.
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Michael Buchholz 2005-06-17, 2:53 am |
| On Fri, 17 Jun 2005 08:46:03 +0200
martin f krafft <madduck@debian.org> wrote:
> Of course blocks are small, e.g. 64 bytes. However, doesn't CBC or
> EBC make sure that every block is chained to its predecessor, making
> even the very last block of a file dependent on the bits of the very
> first block?
No.
If it would be that way, it would allways be necessary to decrypt the
whole filesystem, when you want to read the last block. Or you have to
store a decrypted version in memory...
And also, when you write any block, you have to reencrypt all the
remaining blocks.
I don't know, what kind of CPU you use, but on my system, that would be
really time consuming!!!
The loss of a single block on a harddist "should" be protected by using
some kind of "forward error correction" like the Solomon-Reed one.
--
mit freundlichen Gruessen / with friendly regards
Michael Buchholz
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2005-06-17, 2:53 am |
| also sprach Florian Weimer <fw@deneb.enyo.de> [2005.06.17.0848 +0200]:
> These are *cipher* blocks, and they are chained only within
> a *block device* block.
Who guarantees that? If Cipherblock CB_x depends on CB_(x-1), then
CB_last will indirectly depend on CB_first. If the data are large
enough to span multiple block device blocks, damage to the beginning
of the cipherfile makes the rest of the file unusable, no?
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
"friendships last when each friend thinks he has
a slight superiority over the other."
-- honoré de balzac
| |
| Florian Weimer 2005-06-17, 2:53 am |
| * martin f. krafft:
> also sprach Florian Weimer <fw@deneb.enyo.de> [2005.06.17.0848 +0200]:
>
> Who guarantees that? If Cipherblock CB_x depends on CB_(x-1), then
> CB_last will indirectly depend on CB_first. If the data are large
> enough to span multiple block device blocks, damage to the beginning
> of the cipherfile makes the rest of the file unusable, no?
For each device block, a constant, block-specific IV is used. Device
blocks are not chained together. The block device doesn't know
anything about files, anyway.
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Michael Buchholz 2005-06-17, 2:53 am |
| On Fri, 17 Jun 2005 09:03:57 +0200
martin f krafft <madduck@debian.org> wrote:
> Who guarantees that? If Cipherblock CB_x depends on CB_(x-1), then
> CB_last will indirectly depend on CB_first. If the data are large
> enough to span multiple block device blocks, damage to the beginning
> of the cipherfile makes the rest of the file unusable, no?
That is the reason, why a reasonable clever programmer would not do such
a silly thing.
--
mit freundlichen Gruessen / with friendly regards
Michael Buchholz
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Alexander Zangerl 2005-06-17, 2:53 am |
| | |
| Alexander Zangerl 2005-06-17, 2:53 am |
| | |
| Michael Buchholz 2005-06-17, 2:53 am |
| On Fri, 17 Jun 2005 17:15:32 +1000
Alexander Zangerl <az@bond.edu.au> wrote:
> no, this is subtly wrong. the *encrypted* block affects the decryption
> of the block following it, not the cleartext block.
That's a possible, but unsecure way to do that.
This way, an attacker can try to decrypt any block x by using the
encrypted block x-1 and guessing the passphrase.
When knowing the structure of the filesystem, he will have a chance to
find the passphrase in a reasonable time.
When an attacher HAS TO decrypt the first block of a filesystem, AND
this filesystem starts with a challenge (random data) in the first block
and the real filesystem begins at the second block, there is no way to
guess the passphrase, because the attacker cannot check, if the first
block was decrypted correctly.
If i had to build an encrypted filesystem, i would use clusters of i.e.
8kb, starting with a challenge (256 bytes), followed by data (7.5 kb),
followed by error correction data (256 bytes).
On every write, the first 7 3/4 kb will be encrypted and then the
error-corrction code will we calculated for that data and stored in the
last part of the cluster.
I think, this will give good security with reasonable CPU-effort.
--
mit freundlichen Gruessen / with friendly regards
Michael Buchholz Phone.: +49 231 4755513
Paschknappstr. 13 Mobil.: +49 171 3111861
44265 Dortmund, Germany Fax...: +49 231 4755514
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Alexander Zangerl 2005-06-17, 2:53 am |
| | |
| martin f krafft 2005-06-17, 2:53 am |
| also sprach Alexander Zangerl <az@bond.edu.au> [2005.06.17.0915 +0200]:
> no, this is subtly wrong. the *encrypted* block affects the decryption ofthe
> block following it, not the cleartext block.
>
> one dead block spills junk all over the block+1 when decrypted,
> but the (undamaged) encrypted block+1 is used to decrypt block+2 and
> so on.
Ah, yeah, this makes perfect sense. I *knew* it even. I simply
failed to see the big picture.
So encrypted block devices are not really more dangerous than
clear-text in the end... I suppose with AES you end up losing at
least 64 bytes of data, which could be less without encryption...
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
always remember you're unique, just like everyone else.
| |
| martin f krafft 2005-06-17, 2:53 am |
| also sprach Michael Buchholz <michael@bubi.dnsalias.net> [2005.06.17.0857 +0200]:
> If it would be that way, it would allways be necessary to decrypt
> the whole filesystem, when you want to read the last block. Or you
> have to store a decrypted version in memory...
No, it would not. You only need access to the immediately preceeding
block, since its *cipherdata* are used to encrypt the current block.
> And also, when you write any block, you have to reencrypt all the
> remaining blocks.
Yes, don't you?
> I don't know, what kind of CPU you use, but on my system, that
> would be really time consuming!!!
Just one of those 100 GHz low-end consumer products with 128 cores.
And you? 
> The loss of a single block on a harddist "should" be protected by
> using some kind of "forward error correction" like the
> Solomon-Reed one.
But *is* it?
Before I put my data into a cipher file, I sure as hell want to
know...
What I find a bit peculiar: I have made an 8Mb test file in fs.img,
and I overwrite a small part of it:
(dd if=fs.img bs=1 count=10000; dd if=/dev/urandom bs=1 count=8;
dd if=fs.img bs=1 skip=10008) >| fs2.img
When I mount fs2.img, I get no error... what gives?
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
#include <signature.h>
| |
| Bernd Eckenfels 2005-06-17, 7:58 am |
| In article <20050617064603.GA21188@cirrus.madduck.net> you wrote:
> Of course blocks are small, e.g. 64 bytes. However, doesn't CBC or
> EBC make sure that every block is chained to its predecessor, making
> even the very last block of a file dependent on the bits of the very
> first block?
It is therefore better to use counter mode for clusters.
Bernd
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Horst Pflugstaedt 2005-06-17, 7:58 am |
| On Fri, Jun 17, 2005 at 09:03:57AM +0200, martin f krafft wrote:
> also sprach Florian Weimer <fw@deneb.enyo.de> [2005.06.17.0848 +0200]:
>
> Who guarantees that? If Cipherblock CB_x depends on CB_(x-1), then
> CB_last will indirectly depend on CB_first. If the data are large
> enough to span multiple block device blocks, damage to the beginning
> of the cipherfile makes the rest of the file unusable, no?
wouldn't it be possible to test that?
Scenario:
encrypt /dev/hda7, mount, fill it with some hundred small files (with
known content), unmount, change one bit/byte/block on /dev/hda7 (using dd),
remount, look for the remaining files and their contents.
I can imagine this might work; errors dont' have to be implemented in
hardware, do they?
Greetings
Horst
--
.... I don't know why but, suddenly, I want to discuss declining I.Q.
LEVELS with a blue ribbon SENATE SUB-COMMITTEE!
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bernd Eckenfels 2005-06-17, 7:58 am |
| In article <20050617074620.GA23510@cirrus.madduck.net> you wrote:
> So encrypted block devices are not really more dangerous than
> clear-text in the end... I suppose with AES you end up losing at
> least 64 bytes of data, which could be less without encryption...
You lose much more with RAID-5, yes.
Greetings
Bernd
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2005-06-17, 7:58 am |
| also sprach Horst Pflugstaedt <horst@uni-duisburg.de> [2005.06.17.1018 +0200]:
> encrypt /dev/hda7, mount, fill it with some hundred small files
> (with known content), unmount, change one bit/byte/block on
> /dev/hda7 (using dd), remount, look for the remaining files and
> their contents.
I've tried that and the filesystem mounts without error. I have not
yet figured out where the corruption occurs.
It's an 8M filesystem (twofish) and I put an 8M file of all zeroes
in there. After unmounting and deleting the loop device, I overwrote
four bytes in the file with 0000. Saving, setting up the loop
devices, mounting... no errors.
**And the file is still all zeroes...**
So I guess there is error correction happening?
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
"work consists of whatever a body is obliged to do.
play consists of whatever a body is not obliged to do."
-- mark twain
| |
| Michael Buchholz 2005-06-17, 7:58 am |
| On Fri, 17 Jun 2005 12:01:02 +0200
martin f krafft <madduck@debian.org> wrote:
> devices, mounting... no errors.
>
> **And the file is still all zeroes...**
>
> So I guess there is error correction happening?
Is there something in the logfiles? Maybe the cryptoloop is a little
verbose about errors...
--
mit freundlichen Gruessen / with friendly regards
Michael Buchholz Phone.: +49 231 4755513
Paschknappstr. 13 Mobil.: +49 171 3111861
44265 Dortmund, Germany Fax...: +49 231 4755514
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2005-06-17, 7:58 am |
| also sprach Michael Buchholz <michael@bubi.dnsalias.net> [2005.06.17.1218 +0200]:
> Is there something in the logfiles? Maybe the cryptoloop is a little
> verbose about errors...
Nope. Someone raised the point of a file with all zeroes being
possibly sparse, but I don't think that's the case if I wrote it
with
dd if=/dev/zero of=file bs=8M count=1
right?
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
"there's someone in my head but it's not me."
-- pink floyd, the dark side of the moon, 1972
| |
| Michael Buchholz 2005-06-17, 7:58 am |
| On Fri, 17 Jun 2005 12:30:58 +0200
martin f krafft <madduck@debian.org> wrote:
> Nope. Someone raised the point of a file with all zeroes being
> possibly sparse, but I don't think that's the case if I wrote it
> with
>
> dd if=/dev/zero of=file bs=8M count=1
>
> right?
Right. This file contains 2^23 0x00's.
The other thing, mentioned, will happen with this code:
fd = open ("empty_file", O_WRONLY, 0666);
lseek (fd, 2^23, SEEK_SET);
write (fd, "?", 1);
close (fd);
ls -l will show 8 MB
du -a will show 1k
Maybe, you'll like to try bigger damages to the encrypted fs, until the
error correction breaks.
And maybe, fill the file in the fs from /dev/randon instead of
/dev/zero.
--
mit freundlichen Gruessen / with friendly regards
Michael Buchholz
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2005-06-17, 7:58 am |
| also sprach Michael Buchholz <michael@bubi.dnsalias.net> [2005.06.17.1242 +0200]:
> fd = open ("empty_file", O_WRONLY, 0666);
> lseek (fd, 2^23, SEEK_SET);
> write (fd, "?", 1);
> close (fd);
dd if=/dev/zero of=file bs=1 count=1 seek=8388607
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
"durch frauen werden die höhepunkte des lebens bereichert
und die tiefpunkte vermehrt."
- friedrich nietzsche
| |
| Isaac To 2005-06-17, 5:53 pm |
| >>>>> "martin" == martin f krafft <madduck@debian.org> writes:
[vbcol=seagreen]
martin> Yes, don't you?
Didn't you realize that if that is the case, every single-byte write
would means writing, on average, half the disk, and on a disk of say a
few GB, at the current technology of disk systems, would takes several
hours? But more importantly (you might be thinking about disk cache),
since it is unlikely that you won't be writing some data right before
a reboot, a reboot would take several hours?
Writing a block means writing a block (or at most a few). Nobody can
turn it to writing a disk, if any meaningful performance is wanted.
Regards,
Isaac.
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Ben Pfaff 2005-06-17, 5:53 pm |
| martin f krafft <madduck@debian.org> writes:
> However, doesn't CBC or EBC make sure that every block is
> chained to its predecessor, making even the very last block of
> a file dependent on the bits of the very first block?
Yes and no. If you change the first block in a set of
CBC-chained blocks, the last block will change. But to recover
the contents of the last block, you only need the last block and
the preceding block (and the key).
--
"I was born lazy. I am no lazier now than I was forty years ago,
but that is because I reached the limit forty years ago. You can't
go beyond possibility."
--Mark Twain
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bernd Eckenfels 2005-06-18, 2:48 am |
| In article <20050617103058.GA1367@cirrus.madduck.net> you wrote:
> Nope. Someone raised the point of a file with all zeroes being
> possibly sparse, but I don't think that's the case if I wrote it
> with
have you unmounted the file before writing to it? perhaps you changes was
overwritten with the blok from cache
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2005-06-18, 2:48 am |
| also sprach Bernd Eckenfels <ecki@lina.inka.de> [2005.06.18.0253 +0200]:
> have you unmounted the file before writing to it? perhaps you
> changes was overwritten with the blok from cache
Yes. And my simulated broken blocks were still there after checking
the integrity and unmounting again.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
drink canada dry! you might not succeed, but it *is* fun trying.
| |
| Max Vozeler 2005-06-20, 7:53 am |
| On Fri, Jun 17, 2005 at 12:59:14PM -0700, Ben Pfaff wrote:
> martin f krafft <madduck@debian.org> writes:
>
>
> Yes and no. If you change the first block in a set of
> CBC-chained blocks, the last block will change. But to recover
> the contents of the last block, you only need the last block and
> the preceding block (and the key).
A good explanation of this mode (dubbed "Sector Enciphering Operation")
is in Saarinen's paper about the watermark weakness[1]. cryptoloop and
siblings basically use CBC only within a sector (512 byte), so different
sectors are all independent from each other.
cheers,
Max
[1] http://docs.indymedia.org/twiki/pub...to/wisa2004.pdf
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Phillip Hofmeister 2005-06-22, 5:58 pm |
| On Fri, 17 Jun 2005 at 06:01:02AM -0400, martin f krafft wrote:
> also sprach Horst Pflugstaedt <horst@uni-duisburg.de> [2005.06.17.1018 +0200]:
>
> I've tried that and the filesystem mounts without error. I have not
> yet figured out where the corruption occurs.
You could always run tripwire on the mounted file system, unmount it,
change your block, remount it, and run a tripwire check. This should
identify *WHICH* file changed.
--
Phillip Hofmeister
| |
| Bernd Eckenfels 2005-06-22, 5:58 pm |
| In article <20050622202043.GA21612@antiochcomputerconsulting.com> you wrote:
> You could always run tripwire on the mounted file system, unmount it,
> change your block, remount it, and run a tripwire check. This should
> identify *WHICH* file changed.
he has only one file and this was unaltered, the question is why.
Bernd
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Phillip Hofmeister 2005-06-23, 8:48 pm |
| On Wed, 22 Jun 2005 at 06:32:08PM -0400, Bernd Eckenfels wrote:
> In article <20050622202043.GA21612@antiochcomputerconsulting.com> you wrote:
>
> he has only one file and this was unaltered, the question is why.
Perhaps the block that was changed was a free block?
--
Phillip Hofmeister
--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2005-06-28, 7:50 am |
| also sprach martin f krafft <madduck@debian.org> [2005.06.17.0944 +0200]:
> also sprach Michael Buchholz <michael@bubi.dnsalias.net> [2005.06.17.0857+0200]:
>
> Yes, don't you?
From all I can tell, this is the case for EBC and CBC, but symmetric
cryptography is fast enough these days for this not to be a problem.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer and author: http://debiansystem.info
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
an avocado-tone refrigerator would look good on your resume.
|
|
|
|
|