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

[Behdad Esfahbod]

This all sounds good.  Just about using the free space at the
beginning of the partition, this means that the partition cannot
be used as a boot partition, right?  And worse, trying to install
grub on it erases the sesame data, which doesn't sound great.

behdad


On Sun, 12 Dec 2004, David Zeuthen wrote:

> Hi,
>
> Here are my notes on how to make encrypted filesystems "Just Work(tm)"
> using hal, the Linux kernel device mapper and GNOME (or any other
> desktop that runs on Linux, whee).
>
> I didn't really get down to coding a lot of it; I mostly looked at how I
> think the architecture should look like. It would be great if someone
> can pick this up. I looked a bit around at
>
>  http://www.saout.de/misc/dm-crypt/
>
> to find inspiration. It might be someone already did other tools to do
> this in an easier way, I dunno.
>
> So, these are the different use cases/features that I think a "Just Work
> (tm)" system should support:
>
> 1) The encryption key should be passphrase protected - it must be
> possible to change the passphrase without reencrypting the entire disk.
>
> 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
>
> 3) Ability to have the passphrase protected key on another storage
> device, such as a USB key; this can be used for the use case where a)
> laptop; and b) USB key is required to boot the laptop.
>
> Can also be used in a campus/corporate setting where the sysadmin can
> give the student/worker a key to one or more PC's that can be copied
> onto the users personal USB key. E.g. student X may access workstation
> A, B and C.
>
> 4) Fully automated, e.g. no need to use a shell to get things working.
> Integration with the desktop etc.
>
> So, basically, my position is that to support these usecases we need to
> embed some metadata on the encrypted filesystem saying "this is an
> encrypted filesystem, this is the cipher used, (possibly) this is the
> passphrase protected encryption key and so forth". Note that, AFAICS,
> this is not what people are doing today; they store such metadata on
> other partitions. Which is bad as it means you cannot move partitions
> around easily. However, opponents of my approach might say that it's
> dangerous to give hints (such as cipher used, storing the key only
> protected by a passphrase) to possible attackers - I haven't given that
> much thought yet.
>
> So, anyway, the metadata format is pretty much detailed in [1] and [2].
> I've called the meta data format sesame, since I think that was a pretty
> cool name. YMMV. Anyway, the metadata is just a set of well defined
> key/value pairs. It supports comments.
>
> Hence, there needs to be tools that work with this meta data and hal
> also needs to understand the meta data. The thinking here is that hal
> can actually identify block devices with this meta data, this is not
> difficult, in fact we already have code for identifying regular file
> systems such as ext3, vfat, udf and so on. Here's a screenshot of h-d-m
>
>  http://people.redhat.com/davidz/crypto.png
>
> looking at the such a block device. The tools I think we need are
> discussed in [3] - again, I just picked the name sesame to keep things
> reasonable simple and easy to understand. And I still think it's a cool
> name. Now, given these tools, how are they integrated? Here are my
> thoughts on that, it's pretty straightforward:
>
> Integration with early boot (initrd): Early boot should run sesame-is-
> encrypted on devices to be mounted and if rc is 0, simply run sesame-
> setup and use the device returned on stderr.
>
> Integration with desktop environments: The hal daemon should understand
> block devices with sesame signatures (through volume_id) and sets
>
>  volume.fstype="crypto_sesame"
>  volume.fsusage="crypto"
>
> Also volume.crypto_sesame.* contains all the sesame properties, e.g. the
> property volume.crypto_sesame.block_cipher="aes" if applicable. Further
> volume.uuid will be set to volume.crypto_sesame.uuid.
>
> A program in the desktop session, could be gnome-volume-manager, should
> prompt the user with a dialog asking for either; 1) the passphrase; or
> 2) prompt the user to insert the device with the block encryption key
> and then ask for the passphrase. Said program might also use gnome-
> keyring to cache the passphrase.
>
> Once the passphrase have been obtained in the desktop session, then
>
>  'sesame-setup --device=/dev/sda1 --passphrase=mysecret22'
>
> should be run by root. The desktop session program should probably ask
> hald to invoke this; e.g. by invoking the Setup(string passphrase)
> method on the org.freedesktop.Hal.Device.Crypto.Sesame interface for the
> hal device object representing /dev/sda1.
>
>  (NOTE:  1. hald shall only allow console user to do this
>          2. requires new features in hald to callout a program specified
>             in e.g. the /etc/hal/methods.d/Crypto/Sesame/Setup file)
>
> Finally, since the hal daemon understands the clear text block
> devices, /dev/dm-0 and onwards, provided by dm and hal must knows how to
> add hal device objects for these. Thus, if /dev/dm-0 is really the
> decrypted version of /dev/sda1 then hald must create a hal device object
> representing /dev/dm-0. This device object will be a sibling to the
> device object representing /dev/sda1 and will have the same storage
> device as a parent. Since everything is decrypted, hald will (through
> volume_id) correctly identify the filesystem (say, ext3) and fstab-sync,
> pmount, gnome-volume-manager, whatever, will automount the device.
>
> File managers, such as Nautilus, could integrate "Encrypt Disk",
> "Decrypt Disk" into the context menu/properties page by simply invoking
> methods on the org.fd.Hal.Device.Crypto.Sesame interface.
>
> I've attached a patch against hal HEAD that makes volume_id understand
> the meta data and makes hald understand that if you create a crypto
> target named 'sesame_crypto_<sesame_uuid>' it assigns the same parent as
> the real block device with that uuid and things Just Work(tm).
>
> You can try this out by writing the other attached file,
> crypthead_small2, onto the start a ext3 filesystem (e.g. dd
> if=cryptheader_small2 of=/dev/whatever bs=1 count=512) and invoking the
> right dmsetup command (I forgot the exact one).
>
> Anyway, I've posted this as some people said they were interested in
> working on this. Since I haven't implemented it yet, I may be way off in
> that this is how it should be done. Comments?
>
> Cheers,
> David
>
>
> [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.
>
> This is true for ext3 as the first 1024 bytes are not used (superblock
> is at offset 0x0400).
>
> SESAME metadata format
> ----------------------
>
> # SESAME_MAGIC
> #
> # ^
> # +--- mandatory one line magic marker '# SESAME_MAGIC\n'
> #      Both the metadata stored on the actual block device and
> #      files with metadata must start with these 15 characters
>
> ###################################################################
> # basic fields in metadata
> ###################################################################
>
> # mandatory: Version of sesame metadata
> version            = '0'
>
> # mandatory: UUID for this sesame block device
> uuid               = '1234-5678-9012-3456'
>
> # mandatory: Cipher used for encrypting blocks
> block_cipher       = 'aes'
>
> # mandatory: SHA1 digest of block encryption key
> block_key_sha1     = '01234'
>
> # optional: Data is currently in the clear; encrypt at next boot
> defer              = 'encrypt'
> # optional: Data is currently encrypted; make clear at next boot
> defer              = 'decrypt'
>
> ###################################################################
> # fields in metadata on the block device if the block cipher encryption
> # key is also stored in the metadata
> #
> # Useful for plug and play, e.g. memory sticks
> ###################################################################
>
> # mandatory: cipher user for encrypting the block encryption key
> enckey_cipher      = 'aes'
>
> # mandatory: encrypted block cipher encryption key, e.g.
> # E(block_enc_key, passphr + 'SESAME0')
> enckey             = '0123456789abcdef'
>
> ###################################################################
> # fields in metadata on the block device if the block cipher encryption
> # key is stored on another block device
> #
> # Useful for root filesystem on laptop and key is on e.g. a USB memory
> # key device
> ###################################################################
>
> # optional: FS UUID of device
> #           typically omitted if the key is on several filesystems,
> #           e.g. several USB memory sticks. The UUID is references an
> #           actual UUID from e.g. a ext3 or vfat filesystem depending
> #           on what kind of filesystem contains the file with sesame
> #           metadata
> #
> enckey_on_uuid     = '501f9325-842f-4b96-bce1-0a92af001a4f'
>
> # mandatory: filename of metadata file; SHOULD contain the <uuid> property
> #            in the filename so e.g. one USB memory stick can contain keys
> #            for several partitions
> #
> enckey_filename    = '.SESAME0-key-<uuid>'
>
> # optional: Textual description of the device holding the key; typically
> #           omitted if enckey_on_uuid is omitted (e.g. when key is on several
> #           other block devices). Otherwise used as a hint to the user
> enckey_description = 'davidz's 128MB Jetflash USB Stick'
>
>
> [2] : When the block encryption key is not on the encrypted device it
> must be stored in a file in a filesystem. However, enckey_filename and
> possibly enckey_on_uuid, enckey_description can be used to prompt the
> user to insert the correct device
>
> ###################################################################
> # Example of file holding the key follows here
> # (SHOULD be named .SESAME0-key-1234-5678-9012-3456; CAN be named anything)
> ###################################################################
>
> # SESAME_MAGIC
> uuid          = '1234-5678-9012-3456' # UUID for sesame block device
> enckey_cipher = 'aes'                 # Cipher for encrypting block enc key
> enckey        = '0123456789abcdef'    # E(block_enc_key, passphr + 'SESAME0')
>
> [3] : Some discussion on the set of tools we will need
>
> ############################################################################
> #
> # For use only in a fully booted system (requires hald to be running)
> #
> ############################################################################
>
>
> # Encrypt a disk; used for setting up encryption on a disk
> #
> #  --passphrase can only be omitted if --key-location is given
> #
> #  --key-location means that key shouldn't be stored on the disk; rather
> #    on device with the given mount point
> #
> #  --defer means don't encrypt the disk now; instead do on next boot (will
> #    be done in the initrd); for use on e.g. / or /home that cannot be unmounted
> #
> # (note: potentially unsafe to give the passphrase on the commandline when
> #        exec'ed from another program)
> #
> sesame-encrypt --device=/dev/sda1
>                --passphrase=mysecret22
>                [--key-location=/media/my_usb_disk]
>                [--defer]
>
> # Decrypt a disk; used to remove encryption on a disk
> #
> #  --defer means don't decrypt the disk now; instead do on next boot (will
> #    be done in the initrd); for use on e.g. / or /home that cannot be unmounted
> #
> # (note: potentially unsafe to give the passphrase on the commandline when
> #        exec'ed from another program)
> #
> sesame-decrypt --device=/dev/sda1 --passphrase=mysecret22 [--defer]
>
> ############################################################################
> #
> # For use in the initrd (also works in a fully booted system)
> #
> ############################################################################
>
> # Checks whether /dev/sda1 is encrypted or scheduled to be
> # encrypted/decrypted (by use of --defer). Return value is 0 only
> # if this is the case
> #
> sesame-is-encrypted --device=/dev/sda1
>
> # Setup a device; prompts for passphrase on stdin/stdout unless given;
> # Asks for device with key on if that UUID is not mounted.
> #
> #  If return value is 0 the operation was successfull and the cleartext
> #  device is on stderr
> #
> #  If --defer was used in -encrypt/-decrypt this program will also
> #  encrypt/decrypt the disk once the key is obtained. For --decrypt
> #  the cleartext device returned on stderr will be the same as given
> #  (e.g. /dev/sda1). Will clear the defer property.
> #
> # (note: potentially unsafe to give the passphrase on the commandline when
> #        exec'ed from another program)
> #
> sesame-setup --device=/dev/sda1 [--passphrase=mysecret22]
>
>

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