On Thu, Sep 26, 2013 at 04:48:00PM +0200, Jiri Kosina wrote:
The only two problems I see are
1. The key isn't generational (any compromise obtains it). This can be fixed by using a set of keys generated on each boot and passing in both K_{N-1} and K_N
I think this could be easily made optional, leaving the user with choice of faster or "safer" boot.
Ideally, the key should be regenerated on each true reboot and kept the same if it is just a resume. Unfortunately, I don't see a way to distinguish those before we call ExitBootServices(). The reasoning behind that is that in the case of a kernel compromise, a suspended-and-resumed kernel will still be compromised, so there is no value in passing it a new key. A freshly booted kernel, though, should get a new key, exactly because the attacker could have obtained a key from the previous, compromised one. This speeds up the ususal suspend-and-resume cycle, but provides full security once the user performs a full reboot. The question that remains is how to tell in advance.
2. No external agency other than the next kernel can do the validation since the validating key has to be secret
This is true, but as you said, the relevance of this seems to be rather questionable.
Indeed, it's hard to imagine a scenario that is also valid within the secure boot threat model. -- Vojtech Pavlik Director SUSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org