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

David Zeuthen david at fubar.dk
Fri Dec 17 09:25:56 PST 2004


On Thu, 2004-12-16 at 21:59 -0600, W. Michael Petullo wrote:
> >> I have a prototype "Setup" script written in bash that should allow us
> >> to discuss this portion further.  Before I present the script, here is
> >> the cryptheader I used:
> 
> [...]
> 
> > Anyway, I think this is a good start anyway. Further comments below:
> 
> [...]
> 

I've checked my code into CVS in the sesame module in the hal cvs tree

http://cvs.freedesktop.org/hal/sesame/

as it good to have it close to hal if hald is going to depend on it.

Right now it's pretty simple; the idea is to abstract all metadata
handling into a separate library. Could also have convenience functions
that all the tools will use here. You're welcome to hack and commit to
this - you'll need CVS access, of course, I can set that up if you're
interested (I have to add svu as well, will do it soon svu!), let me
know off list.

(Btw, this module shouldn't depend on hal as hald will use libsesame to
get the metadata; instead we should have a separate module, sesame-hal,
with the tools hal will use - that module will depend on sesame and hal;
we can create that later)

> Okay, I made some changes to the prototype script.
> 
> 1.  I now verify volume.fstype is crypto_sesame.
> 2.  I now ensure the cleartext key ends in SESAME0.
> 3.  I now strip SESAME0 from the key before unlocking the filesystem.
> 4.  I now name the dm-crypt device "sesame_crypto_"$UUID"
> 
> Should the SHA-1 hash of the key be performed with or without the SESAME0
> at the end?  

Yeah, the idea for having the SHA1 digest would be, in the future, to
ask e.g. a personal smart card for the key with this digest (of course,
the user would possibly need to authenticate to this device in a
different manner - e.g. something you have + something you are/know).

The only reason for the trailing SESAME0 is to verify that we're using
the right key. So, yes, the SHA1 digest needs to include the trailing
SESAME0.

> Is my SESAME0-handling logic right?  Once the everything
> seems right I will take a shot at implementing this in C as a statically
> linked program so it may be used in and initrd.  

Cool.

> Does anyone have a
> suggestion for a crypto library (my experience is with OpenSSL/libcrypto)?
> 

No idea; perhaps you can use loopback devices and the kernel crypto?
OTOH, statically linking against the openssl library will also work I
guess. Though I guess it's more politically correct to use GNU TLS these
days; I could be wrong though.

> Here is the new script:
> 
> ===============================================================================
> # FIXME: should be able to get this from the environment.
> UDI=/org/freedesktop/Hal/devices/block_0123-4567-89ab-cdef
> 

Actually sesame-setup should just take the device file. How we set this
up with transferring the Setup() method to this binary is another matter
though; we might want a wrapper of some sort.

> # FIXME: should be able to read this from stdin.
> PASSPHRASE=sesame
> 
> # Get information from hal, should be available from environment someday.
> # May want to read some of this directly from device in case hal is not running.
> BLOCK_KEY_CIPHER=`hal-get-property --udi="$UDI" --key volume.crypto_sesame.block_key_cipher`
> BLOCK_KEY_SHA1=`hal-get-property --udi="$UDI" --key volume.crypto_sesame.block_key_sha1`
> UUID=`hal-get-property --udi="$UDI" --key volume.crypto_sesame.uuid`
> VERSION=`hal-get-property --udi="$UDI" --key volume.crypto_sesame.version`
> DEVICE=`hal-get-property --udi="$UDI" --key block.device`
> VOLUME_FSTYPE=`hal-get-property --udi="$UDI" --key volume.fstype`
> 
> # FIXME: this should be published by hal -- a 128 bit key (as hex).
> # For some reason hald is not providing this information.
> #
> # Key was created with:
> #
> # echo `dd if=/dev/urandom bs=1c count=128`SESAME0 | \
> #   openssl enc -aes-256-ecb | xxd -p
> #
> # Passphrase is "sesame" (see PASSPHRASE defined above)
> ENC_KEY="53616c7465645f5ffc40acbfd4bcdc9052446acdbe9cbfc14b474683b02ffbd3518795255d747f872262590feeb0c33a885da29fa3efe5eb6f9739fbf18c3531c19cc95734a2c9dbab6b965f2d5494acab8460722ab349a3b856734ff2af054b65cc43ce8d138d5160447fb9e71a3d78b09024923c45d216288cec9912a86adf5da2fb470ea856cf0068fba3f478a9b9591bfd148b179b8f7dcdf973e3f2d08c"
> 
> # Make sure volume has correct fstype.
> if [ x"$VOLUME_FSTYPE" != xcrypto_sesame ]; then
>         echo fstype is not crypto_sesame >&2
>         exit 1
> fi
> 
> # Decrypt the key using the passphrase.
> # FIXME: uh oh, how do I pass both passphrase and data to openssl?
> KEY=`echo "$ENC_KEY" | xxd -r -p | openssl enc -d -aes-256-ecb -pass "pass:$PASSPHRASE"`
> 
> # Ensure cleartext key ends in SESAME0.
> echo $KEY | grep SESAME0$ > /dev/null
> if [ $? != 0 ]; then
>         echo cleartext key does not end in SESAME0 >&2
>         exit 1
> fi
> 
> # Strip SESAME0.
> KEY=`echo $KEY | sed 's/SESAME0$//g'`
> 
> # Check to make sure hash of key matches that provided by hal.
> if [ "$BLOCK_KEY_SHA1" != `echo $KEY | sha1sum | awk '{ print $1 }'` ]; then
>         echo key sha1 hash does not match data provided by hal >&2
>         exit 1
> fi

Need to do the SHA1 digest off the key before chopping SESAME0 off it.

> 
> # Set up the dm-crypt device.
> echo setting up $DEVICE using $BLOCK_KEY_CIPHER, default hash and 128 bit key
> echo "$KEY" | cryptsetup -s 128 -c "$BLOCK_KEY_CIPHER" create sesame_crypto_"$UUID" "$DEVICE"
> ===============================================================================
> 

Apart from the SHA1 I think this looks pretty good - does it work?

Cheers,
David

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



More information about the Hal mailing list