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

[W. Michael Petullo]

>> 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:

> Well, ideally sesame-setup must not rely on hald running since we want
> to use it in the initrd to mount /. Hence, it needs to read the metadata
> off the device itself.
>
> As such, it would be a good idea to create a libsesame library that
> various things, including hald, can link against to read/write the
> metadata. If you're interested in this approach I've got the start of
> such a library.

Please send me the beginning of your library.  I would like to take a look
at it and might be interested in maintaining it.

> Do you use the patch that I posted? h-d-m should look somewhat like this
>
> http://people.redhat.com/davidz/crypto.png
>
> Btw, I have just committed the patch, with fixes (see below), to HEAD.

Yes, I am using your patch.

> Should check for volume.fstype==crypto_sesame and bail out if not.

Make's sense.

>> # FIXME: this should be provided by hal when this script is executed.
>> UDI=/org/freedesktop/Hal/devices/block_0123-4567-89ab-cdef

> Right, you will get this from the environment.

>> PASSPHRASE=sesame

> From stdin.

> I want to pass all the hal properties in the environment for method.d
> invocation, so you should be able to use
> $HAL_PROP_VOLUME_CRYPTO_SESAME_UUID and so forth. Of course, that won't
> work before we have the methods.d stuff.

Wait, doesn't this contradict what you said about reading this directly
from the device so that things work without HAL running?  Here is what I
see as the source for parameters:

UDI or device name: environment variable and/or command line argument
Passphrase: stdin
Everything else: read from device

>> # FIXME: this should be published by hal -- a 128 bit key (as hex).
>> # for some reason hald is not providing this information.
[...]
>> ENC_KEY="53616c7465645f5f1e2a1d6798d8eb7aa3b74645d3e12138e7fa974bf06fa8cbfc0d82ec71f63ec9f38c1e0d624b0627a6ba85308ed2a3e0f288777f2c10fd35683ad952dff63603293459b98089b22c98294ff1a57a5b9ff0f74961388e0c6c2755c6b9b3d4a158a62a184df2a934066bb7793c4590096409cd9762979319cda4ead189b28176c62386013a6de4ef76d42396e668dadc9d641779e0a8db81cf"

> This should be volume.crypto_sesame.enc_key, what properties are on the
> UDI you're looking at? (either lshal output or h-d-m screenshot link).
> The reason this didn't show up was that the sesame metadata parser was
> only reading 256 bytes; I've fixed that on HEAD. Now the metadata can be
> up to 1024 bytes which I think should be sufficient. I used shorter keys
> for my testing, I guess that's why.

I was looking at a patched h-d-m, running on my system.  I will try the
new cvs HEAD to see if this fixes things.

>> # 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"`
>>
>> # 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

> You should rather check that the cleartext key ends with SESAME0, cf. the
> spec

Right.  I missed this.

> Need to strip off SESAME0 from the passphrase.

Right again.

> Uh, oh, the name needs to be sesame_crypto_<sesame_udi>, e.g. in your
> case it should be creating the device
> node /dev/mapper/sesame_crypto_0123-4567-89ab-cdef.

Okay.

--
Mike

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