[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.00.1302261427020.14180@twin.jikos.cz>
Date: Tue, 26 Feb 2013 14:34:17 +0100 (CET)
From: Jiri Kosina <jkosina@...e.cz>
To: David Howells <dhowells@...hat.com>
Cc: Florian Weimer <fw@...eb.enyo.de>,
Matthew Garrett <mjg59@...f.ucam.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Josh Boyer <jwboyer@...hat.com>,
Peter Jones <pjones@...hat.com>,
Vivek Goyal <vgoyal@...hat.com>,
Kees Cook <keescook@...omium.org>, keyrings@...ux-nfs.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Load keys from signed PE binaries
On Mon, 25 Feb 2013, David Howells wrote:
> (G) Suspend to disk. This is not permitted if it's possible to then alter
> the image and resume it.
Tangetial to this discussion, but worth mentioning anyway: this can be
solved in a secure way in cooperation with trusted bootloader (such as
shim); bootloader can be (re-)generating a new keypair on each and every
boot, providing it to kernel. Kernel then signs the hibernation image and
discards the private key.
During resume, the image signature (as public key still exists) can be
verified, and new keypair is generated for potential subsequent
hibernation again.
The public key is preserved in trusted UEFI variable, giving it the
exactly same level of security as for example MOK has.
This still has some challenges (having enough entropy available for
keypair generation in bootloader is unlikely, but PRNG might be
sufficient), but it is doable.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists