Currently if you want to have multiple encrypted partitions (ignoring swap and similar recreated-each-time partitions) you have to enter either a password or a pgp password for each partition. This patch changes that. The basic outline of the patch is that you have a "master" keyfile. This is encrypted using one id and requires the user to supply the passphrase. It contains the passphrase for the id used to encrypt the keyfiles. Therefore, the passphrase is asked for once and all the different partitions that are desired to be encrypted can be opened in one go. Patch should be attached. Reproducible: Always Steps to Reproduce: 1. Add the patch. 2. Setup the gpg/pgp id's and the slave id's passphrase being encrypted with the master's id. 3. Store the keys for each partition encrypted with the slave's id. Actual Results: All partitions are mounted with only one passphrase request. Expected Results: Without the patch you are required to enter passphrases multiple times. Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r1, 2.6.11.10 i686) ================================================================= System uname: 2.6.11.10 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium4 -funroll-loops -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -funroll-loops -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_GB.UTF-8" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/gentoo/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.asia.gentoo.org/gentoo-portage" USE="x86 X alsa apm avi berkdb bitmap-fonts cdr cjk crypt curl dga dmx dvd eds emacs emboss encode exiscan-acl fam flac foomaticdb gd gdbm gif gnome gstreamer gtk gtk2 imagemagick imlib jpeg ldap libg++ libwww live mad mbox mikmod mmx motif mp3 mpeg mule ncurses nls ogg oggvorbis opengl oss pam pdflib perl png python readline real sdl server slang spell sse ssl tcltk tcpd tetex threads tiff truetype truetype-fonts type1-fonts unicode usb vorbis xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS
Created attachment 67342 [details, diff] This updates dm-crypt-start.sh to include the master_key functionality.
Sorry about the delay but i've been busy. At a quick look this diff does not apply cleanly to the dm-crypt-start.sh in portage. Can you verify that it does and if it doesn't submit a new one. Also please include all other relevant steps ie changes to config files and steps in gpg so that others aside from myself reading this know what you mean :)
Created attachment 70448 [details, diff] Patch for dm-crypt-start.sh to add master capability. I've changed the diff. It did patch cleanly if you did a patch -l 8-). How to use the new functionality: This is assuming you're already happy to set up cryptsetup using a PGP key. I.e. you know how to create the key in the right place, create the partition with the key and put the encrypted key in the right place. We are going to need 1 key for each partition, and one extra. 1) Create all the partition keys, and the partitions using them. 2) Create a "master" key. This master key will be used as the passphrase to unlock the other keys. 3) Now create two GPG keys. For the first one use the "master" key as the passphrase. 4) Encrypt the partition keys with the first account. 5) Add the lines to /etc/conf.d/cryptfs as you would have before, pointing the key at the encrypted keys. 6) Encrypt the "master" key with the second account. 7) Add a line to /etc/conf.d/cryptfs, before the first mount, that says "master_key='<where_you_have_the_encrypted_master_key>'". 8) Test. 9) Get rid of all the unencrypted keys. Strictly speaking line 7 is wrong. You have to add the master_key line before the first mount that uses the "master" key to encrypt the partition keys. You can have other mounts under the current system as well if you want but they must be before the first mention of master_key. If you have two master_keys then you can use two sets of keys so that two passphrases are required to get into the complete set of partitions. (Why you would do this is beyond me. If you want to type in lots of passphrases then ignore the master_key system completely.) If you don't want to use the master_key functionality then just not having any line starting with master_key returns to the previous functionality. I hope this is clear. Feel free to ask for more clarification.
now I understand my problem, I was trying to patch the cryptsetup-luks script. Would you mind looking at making a diff for the cryptsetup-luks dm-crypt-start.sh as this is the package that is supported and recommended going forwards (the cryptsetup author himself admits that cryptsetup is fully deprecated by cryptsetup-luks). If you don't have the time / can't be bothered I will do it but as I'm running low on time I would appreciate a patch from you :) thanks for your contribution, one other thing, you might want to expand on the gpg key creation ie step by step. (i'm going to write a HOWTO on this soon as its causing a lot of confusion).
I'll have a look at this when I get some time. I've already had a quick look at it and it doesn't appear to be too difficult to port across.
Created attachment 73278 [details, diff] Patch for dm-crypt-start.sh to add master capability. (against sys-fs/cryptsetup-luks) This is a patch against cryptsetup-luks giving master passphrase capability. In addition to the previous possibilities it also allows the use of luks's multiple passphrases so that you can just encrypt one passphrase to use to unlock each partition, ala luks mode. You still have to gpg encrypt a master passphrase though, just not the separate partition keys. Sorry it is so late. Life got in the way and then I had some questions about security issues to overcome.
Created attachment 73279 [details, diff] Patch for dm-crypt-start.sh to add master capability. (against sys-fs/cryptsetup-luks) This is a patch against cryptsetup-luks giving master passphrase capability. In addition to the previous possibilities it also allows the use of luks's multiple passphrases so that you can just encrypt one passphrase to use to unlock each partition, ala luks mode. You still have to gpg encrypt a master passphrase though, just not the separate partition keys. Sorry it is so late. Life got in the way and then I had some questions about security issues to overcome.
thanks for your contribution. I will run some tests myself over the next little while and add to portage shortly assuming all is in order.
Out of curiousity have you tested this and got it running on a live system? Can you include an example /etc/conf.d/cryptfs? I am trying a few things now but running into some problems and would like to see what your cryptfs looks like before I make any changes.
I've solved the previous problems and have one issue remaining (well two, but that is more of a user error as using --key-file when using a small test pass phrase will be automatically padded and is therefore not the same as echo passphrase | cryptsetup etc etc) and that is that we currently don't have a static gnupg ebuild for 1.9. That said it otherwise looks fine. I shall look to include it soon.
further testing has shown this patch is not working as you have it documented. Can you confirm that you have tested this and set it up on a machine? If you have can you please send me the /etc/conf.d/cryptfs that you are using, but from what I can see this script will not work as it is.
Created attachment 75094 [details, diff] Updated patch to add master support to cryptsetup-luks. This doesn't do very much error checking. In particular it doesn't check that the user has put their gpg keys in the right place, which is /.gnupg/ and not /root/.gnupg/. Not sure how much error checking should be present in a config file, but getting this one wrong is pretty nasty.
Any progress on this?
I'll be looking at this shortly, I was away for a while and I've not had access to my test kit for even longer. I should get around to it in the next week or so.
superceded by 1.0.3-r3, closing this bug. Feel free to raise a new bug if you have functionality that you think the new version misses but make the diffs against the new scripts.
