My notes on making encrypted filesystems "Just Work(tm)"

[David Zeuthen]

On Mon, 2004-12-13 at 11:41 +0100, Martin Pitt wrote: 
> Hi David!
> 
> Incidentially we talked about exactly the same issue on the Ubuntu
> conference and I would very much like to cooperate with you on this
> issue.
> 

Cool, there's plenty of space on this server if you need CVS; my initial
thought was to store it in the sesame module right next to hal.

> Right now we want to start with supporting encrypted removable
> devices, but the metadata design should be extensible enough to
> support encrypted home (and other) file systems as well.
> 

Right.

> David Zeuthen [2004-12-12 21:47 -0500]:
> > 1) Support encryption of hotpluggable devices, e.g. USB keys. Used by
> > the office worker Abby to safely store documents she exchanges with her
> > coworkers. This means that Abby should be able to plug her USB key into
> > her colleagues laptop and the a dialog to enter the passphrase should be
> > offered.
> > 
> > 2) Support encryption of root file systems; e.g. encrypt all data on a
> > laptop computer
> 
> > [1] : Here follows what metadata is stored on the actual block device
> > that is encrypted; for this to work there must be at least 512 bytes (or 
> > something) somewhere well known on the block device that we can overwrite
> > with a guarantee that the filesystem will still work. It also requires the
> > encryption to be a block-based cipher as we will overwrite the portions
> > of the crypted block device.
> 
> In the interest of supporting encrypted home directories I propose to
> not define a fixed size for the metadata. Instead the first block
> should specify how many further metadata blocks are used (the dm
> device then starts at the block right after the metadata).
> 

Yeah, I'm a bit scared of that. One of the important use cases in my
view is the ability to easily encrypt/decrypt a file system (on the fly,
for USB keys, or on the next boot) without changing it's size [1]. For
ext3 that means we only got 0x400 bytes in the beginning of the file
system.

[1] : The obvious use case is if you want to exchange data with e.g.
Windows and there is not yet support for the encryption schemes we use
in Windows.

> With a flexible amount of metadata it would be possible to implement a
> "keyring", i. e. a structure which maps user ids to the device
> password encrypted with the user's password. This could then be
> integrated nicely with libpam-mount for e. g. encrypted /home
> partition support.
> 
> What do you think about that?
> 

The user id's are going to be tied into /etc/password anyway so I
suspect you could just leave the meta data file on the / partition? With
my proposal you would set 

# UUID of the filesystem from the / partition
enckey_on_uuid     = '501f9325-842f-4b96-bce1-0a92af001a4f'

# Metadata file containing (multiple) passphrase protected key(s)
enckey_filename    = '/etc/SESAME0-key-<uuid>'

I like the idea of having multiple passphrase protected keys in the same
metadata file but I suspect it's making it's easier to crack the
encryption key? /me goes off to find Schneier's book.

How would that work out?

Cheers,
David


_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal