encrypted root filesystem

Dagmar d'Surreal dagmar.wants at nospam.com
Mon Feb 23 15:52:59 PST 2004


On Mon, 2004-02-23 at 16:43, Ian Molton wrote:
> On Mon, 23 Feb 2004 15:54:22 -0600
> Dagmar d'Surreal <dagmar.wants at nospam.com> wrote:
> 
> > > > The Encrypted-Root-Filesystem-HOWTO doesn't encrypted the
> > > > partition table. 
> > > 
> > > encrypted filesystems are stupid.
> > 
> > No, they're not.  You should be ashamed of yourself for posting such a
> > comment.
> 
> I remain unconvinced. encrypting an entire filesystem gives you loads of
> known plaintext (and binaries, potentially).

The plaintext isn't as known as it would first appear.  While it might
be known that there's a chunk of text data from a default configuration
file in there somewhere, the _where_ is a fairly serious unknown since
when the filesystem is encrypted, so is the directory structure and
inode tables are encrypted as well.

> I havent seen a problem yet that isnt better solved by application level
> crypto.

Ouch.  That tends to be _lot_ more trouble than it's worth.  I've seen
some LD_PRELOAD toys that can begin to do that, but then you have to
assume you know which apps are going to need it, and then an attacker
will have much less data to search through to try to find the goodies,
since only "important" things will be encrypted.  You also have to
assume that someone is only going to be accessing their filesystem with
untainted programs.  This is similar to the problem with the PAM module
for mounting encrypted home directories... while the filesystem is
mounted and readable, it's pretty much fair game.  For this much trouble
one might as well encrypt the whole thing and get the benefit of knowing
their OS binaries weren't tampered with while they were away.

For some people, software implementations aren't going to be necessary. 
IBM makes several laptops which come with an optional feature (it's not
on their cheapie models, but it doesn't cost extra either) that while
primarily deterring theft, protects the data to a degree that requires
some pretty hefty hardware tampering to get around.  A password can be
set in the BIOS that actually gets stored in the HD so that the machine
won't boot without the entered password and the hard drive won't read
without the BIOS passing it the correct password.  Set a password on the
notebook, take the drive out and put it on another machine, and the
drive won't even respond to ATA calls--it will merely sound a tinny
alarm through it's own teensy speaker.  Putting a new drive in the
notebook and entering the correct password or clearing the BIOS won't
get the chassis working again, either.  The only way to get at the data
on the hard drive is to take the drive apart and put a different
controller board on it, and then proceed to break the encryption.
-- 
The email address above is phony because my penis is already large enough, kthx. 
              AIM: evilDagmar  Jabber: evilDagmar at jabber.org




More information about the hlfs-dev mailing list