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.