Experience and observations of F11a/rawhide so far

Matthew Hall lists at ecsc.co.uk
Wed Mar 25 10:55:23 UTC 2009


On 15/03/09 23:22, Keith G. Robertson-Turner wrote:
> One request I would like to throw out there, as a RFE, is the ability to
> specify *keyfiles* instead of a password, when anaconda is setting up an
> encrypted filesystem with cryptsetup. My current arrangement requires me
> to manually edit the initrd thus:
>
> echo Setting up disk encryption: SecureKeys
> cryptsetup luksOpen /dev/sdb1 SecureKeys
> mkdir /SecureKeys
> mount -t ext3 /dev/mapper/SecureKeys /SecureKeys
> echo Setting up disk encryption: takeMScrypt
> cryptsetup luksOpen /dev/sda2 takeMScrypt
>     --key-file=/SecureKeys/takeMScrypt.key
> echo Closing encryption keys volume: SecureKeys
> umount /SecureKeys
> cryptsetup luksClose SecureKeys
>
> sda is a USB keychain, with a built in MicroSDHC card reader.
> sda1 is "/boot", unencrypted.
> sda2 is "/" on an LVM volume encrypted with the kefile on sdb1.
>
> sdb is a MicroSDHC card, with the key store on sdb1, which is itself
> password encrypted.
>
> So when this boots, I'm asked for a password once, which unlocks the key
> store, and uses keyfiles in that key store to unlock the other
> filesystems, then closes and unmounts the keystore, so the MicroSDHC
> card can be physically removed (and possibly hidden).
>
> How easy would it be to build something like this into anaconda?

I've attached the patch to rc.sysinit I use in-house here to achieve a 
similar thing.

In short, all my users' gpg keys are held in /etc/gnupg 
(root.root/0700); and have a usb key which has a small (4k) bit of 
random data from /dev/random which is gpg encrypted to everyone's public 
keys. /etc/crypttab is then modified to use '/mnt/.home.key.gpg' instead 
of 'none'.

I then add the keyfile to the luks partition with cryptsetup (any 
passphrases can be kept if you're wary about losing the ability to 
decrypt - simply don't remove the passphrase from the luks partition and 
don't plug the usb stick in when booting).

Plymouth passes the passphrase requested into Gpg then decrypts the 
keyfile which is then passed into cryptsetup to unlock the partition via 
stdin/out.

This way, a users laptop, usb key and passphrase would have to fall into 
the hands of an attacker to get to your data.

-- 
Regards,

Matthew Hall (BSc, CISSP, CEH)
Security Engineer
ECSC Ltd
01274 513266

This email is intended solely for the addressee, and is strictly
confidential. The content does not comprise professional advice, and you
should seek suitable specific advice from us before acting in any way
upon it. Additional terms and conditions are available at
http://www.ecsc.co.uk/cond_serv.html
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rc.sysinit-usbkey.patch
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090325/17d79c37/attachment.ksh>


More information about the fedora-devel-list mailing list