FWIW, this doesn't *precisely* belong on -hardened, but since much of the audience for secured booting is the same I doubt many will complain.
On Wed, Nov 18, 2009 at 12:20:13AM +0100, Marcel Meyer wrote: > Now I'd like to try to use the usb-key just as a generic loader for an > already > encrypted kernel on the harddrive. The kernel/initramfs of the USB key loads > the LUKS-partition and instead of booting this system with the already loaded > kernel from the USB key it should replace the running kernel with another one > incl. initramfs from the harddrive using kexec from the encrypted partition. I'm following you all the way up to the kexec - what exactly are you trying to solve by doing that? The only approach more protected against physical compromise is a TPM-integrated boot where you seal the LUKS key to your particular BIOS/bootloader/kernel/initrd measurement, but that's not quite possible in the Linux world yet. If the kernel or initrd on the USB key are compromised (which it seems you're trying to protect against), they're under no obligation to follow the kexec path. Once you've unlocked the LUKS partition the kimono has dropped, so to speak, and they're free to do whatever malicious deeds they wish. You could raise the bar on that a little by using write-once media like an optical disc instead of a USB key, and even make it visually "unique" by physically modifying the disc in some manner that doesn't damage its readability, but you're still just engaging in an arms race. Look at bug #204830 for a start on the TPM integration. What's missing right now is an initrd-usable app (not all of TrouSerS) that would replace GPG in your use case, unsealing the key from the TPM and passing it on to cryptsetup. I expect cryptsetup could be modified to do the job itself, but that's beyond my level of knowledge right now.
