> I think it is not a problem to decrypt the key file in the startup process, > isn't it!? Is it possible to access the card reader (omnikey 4040) and the > smartcard via gpg from the initrd ram disk? Has anyone ever tried it in a > similar way or are there any alternatives? Finally, is there a HowTo?
I hacked this together on Debian squeeze. It might need a little work to get it working under another distribution. But I did not use LUKS; LUKS is based on passwords and I use the asymmetric crypto of the OpenPGP card, so I figured it made more sense to literally store the encryption key in a file encrypted to the card. I use the cryptsetup package for this (which also handles the LUKS drives, by the way). The basic idea is to include the gpg binary and its libraries, especially libusb-0.1.so.4. The libraries are handled automatically by initramfs-tools, and most, if not all except for libusb, of the libraries are already in the default initramfs. The biggest problem is that gnupg opens /dev/tty and this is not available in the initramfs. This might actually be a bug in initramfs-tools, I'm not sure. To hack a fix, I changed gnupg to open /dev/console instead. This is a hack that will only work in a very limited number of cases, so the binary I create this way is special-purpose for the initramfs. See the diff[1] below. I then use the debian build programs to build a .deb, and from that .deb extract /usr/bin/gpg. I move that binary to /usr/local/lib/cryptsetup/gpg-console (note that gpg-console is the name of the binary, not a directory). There are obviously different ways of compiling. I was just hacking something together and the default Debian binary was fine except for the /dev/tty thing, so I chose to build it the same way as the normal Debian binary, without even looking at other ways like a simple "make". The cryptsetup package uses entries in /etc/crypttab for the encrypted partitions. I use something like the following entry: root_crypt /dev/mapper/vg1-root /etc/gpgcryptroot/root.gpg cipher=aes-cbc-essiv:sha256,size=128,hash=plain, keyscript=/etc/gpgcryptroot/decrypt_gpg This should be one line. vg1-root is the LVM logical volume root in volume group vg1. Next are the scripts for including and using gnupg in the initramfs. They are highly initramfs-tools specific. Secondly, they are a little big to include in this mail, so I uploaded them to [2]. This also includes the diff mentioned before. The actual decryption is done by the script /etc/gpgcryptroot/decrypt_gpg. It does a crude check to see if it is running in the initramfs. If it is not, it takes a different approach more suitable for activating partitions from a fully running system instead of the initramfs. I'll come back to that later. The script expects a directory with at least the following files: pubring.gpg A limited public-key ring, containing only the needed key that is on the smartcard. secring.gpg The limited secret-key ring, again only the needed smartcard key. root.gpg They key to unlock the root. The name is irrelevant (but needs to match the /etc/crypttab entry). It is just the literal key material cryptsetup expects; 16 bytes for AES-128 as above. Optionally a gpg.conf could be placed there if it is necessary for gpg to function correctly. I placed these files at /etc/gpgcryptroot, together with the script. Please mind the access permissions on the files and the directory; gpg expects them to be "secure" and complains otherwise. The decrypt_gpg script invokes the special-purpose gpg binary, and it asks for the PIN of the smartcard. The contents of the decrypted key file are passed to cryptsetup. The final script glues together the other components with the initramfs. I derived it from /usr/share/initramfs-tools/hooks/cryptopensc from the cryptsetup package. It should be placed at /etc/initramfs-tools/hooks/cryptgpg. The /etc/crypttab entry indicates where the files pubring.gpg, secring.gpg, root.gpg and optionally gpg.conf are, and the script copies them to the initramfs. It also copies the /usr/local/lib/cryptsetup/gpg-console binaries and its libraries to the initramfs. A few final words on which partitions (mount points) can be encrypted with this hacked-together scheme. The root is the obvious target and the only one that is somewhat tested. /boot can not be encrypted. This is a fundamental limitation; unless the BIOS or boot loader can do the decryption, you will always need something unencrypted to start from. /usr, as a separate partition, can also not be encrypted without further tweaks, because the script works either in the initramfs, or in a system with /usr/bin and possibly more already mounted. For the system I use it on, everything is in one partition. It's not my normal workstation but a protected environment to do my super secret stuff in ;). The part of the script that does acces to encrypted partitions in a fully booted system expects gpg to be able to decrypt the file succesfully with its default settings. In fact, as a horrible kludge, I use "su" to load the environment normally encountered when root logs in, as environment for gpg to run in. By default, cryptsetup gives a really limited environment to the keyscripts, and this was the first I thought of that works. With "gpg with its default settings", I mean home directory, keyrings, etcetera. I hope this all is somewhat clear. It is definitely not a step-by-step HOWTO, requires some Linux skills and is completely not peer reviewed ;). Good luck, Peter. [1] --- gnupg-1.4.9/util/ttyio.c 2007-10-23 09:55:31.000000000 +0200 +++ gnupg-1.4.9-new/util/ttyio.c 2009-10-05 17:54:25.000000000 +0200 @@ -106,7 +106,7 @@ #endif /* Assume the standard tty on memory error or when there is no ctermid. */ - return name? name : "/dev/tty"; + return "/dev/console"; } [2]<http://wwwhome.ewi.utwente.nl/~lebbing/gpgcryptroot.tar.gz> _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users