Thank you for dealing with my message :-)
Am Mittwoch, 18. November 2009 02:03:23 schrieb sch...@subverted.org: > 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. Hehe, yes. And it's a hardened system (of course). And I have hardened compiler problems ;-). Aaand there was no traffic on gentoo-hardened for about a month. We have to check if the list is still working :-) > 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? Well, several things. First: convenience and reliability. By having a more or less static kernel and initramfs with a small, generic subset of modules which can boot all of my computers, I can reuse this USB stick (with several key/password-combinations) for more than one machine. And when updating the kernel and/or the modules on my "work-kernel" I don't have to remember adding it to the USB-stick and keeping it consistant. So updating because of the newest graphics card driver is a little less trouble. > [..] > 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. Second: a little bit more security (by obscurity...?). You are right that a running kernel could do a lot of harm when having access to the data. But when that kernel on the USB stick decrypts a trustworthy kernel from the /boot on HD, calls kexec on it (the /sbin/init on this boot partition will have to do that) and this kernel then decrypts the /-partition with another password/key- combination, shouldn't this help a little bit? I mean I can not prevent this potential corrupted kernel from starting and then accessing my /boot partition. But as long as the "attacker" did not invest so much work to keep this kernel alive "behind" a kexec call or starting some virtual machine etc. pp., the newly started kernel should take full control - and if something different (like another kernel from the USB- stick) is started, I will recognize that and don't enter the password for the data. So my main question here is: does it make sense to replace the first kernel by a trusted second one or is it too easy to hide behind such functionality? Of course this will not detain any serious hackers - besides they would have better methods like adding simple hardware hacks. But would this work as a protection against by-chance-hacker, getting somehow their hands on the key for a short time? > 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. Thank you for that hint! I will follow it since at least my newest notebook now has some TPM chip inside. I already searched for some USB tokens so that they can't be copied at least. But that still wouldn't help with the problem of a modified initramfs which sends stuff over the network, f.ex. Thanks, Marcel
