From: Andy Lutomirski <luto@kernel.org>
To: "Luis R. Rodriguez" <mcgrof@suse.com>,
linux-security-module@vger.kernel.org, james.l.morris@oracle.com,
serge@hallyn.com
Cc: linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
David Howells <dhowells@redhat.com>,
Kyle McMartin <kyle@kernel.org>,
David Woodhouse <david.woodhouse@intel.com>,
Seth Forshee <seth.forshee@canonical.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Joey Lee <jlee@suse.de>, Rusty Russell <rusty@rustcorp.com.au>,
zohar@linux.vnet.ibm.com, mricon@kernel.org,
Michal Marek <mmarek@suse.cz>,
Abelardo Ricart III <aricart@memnix.com>,
Sedat Dilek <sedat.dilek@gmail.com>,
keyrings@linux-nfs.org, Rusty Russell <rusty@rustcorp.com.au>,
LSM List <linux-security-module@vger.kernel.org>,
Borislav Petkov <bp@alien8.de>, Jiri Kosina <jkosina@suse.cz>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFD] linux-firmware key arrangement for firmware signing
Date: Tue, 19 May 2015 13:59:36 -0700 [thread overview]
Message-ID: <555BA438.2070802@kernel.org> (raw)
In-Reply-To: <20150519200232.GM23057@wotan.suse.de>
[added cc's from the other thread]
On 05/19/2015 01:02 PM, Luis R. Rodriguez wrote:
> David Howells has posted v4 of his series of supporting PKCS#7 for module
> signing. I'm in my v3 series now on RFCs for firmware PKCS#7 support, and after
> some review and patch shuffling I think this is ready for patch form. My own
> series however depend on quite a bit of other pending changes, one series which
> will go through Rusty's tree, another series of fixes on firmware_class which
> should go through Greg's tree. I'll wait until all this and David's own patches
> get merged before posting firmware PKCS#7 support. Before all this though in
> preparation for fw signing one thing we should start to talk about more broadly
> however is how linux-firmware binary file signing would work in practice and
> what we need, and make sure folks are OK with all this.
>
> First, firmware signing will be completely optional as with module signing.
>
...
> Other than this last nitpick, any other concerns or recommendations ?
A couple. Some of these are general concerns with the existing
infrastructure, but #1 is a specific problem that gets much worse if we
add firmware signing. Feel free to ignore 2-4.
1. We should get the signature semantics right. I think that, for
modules, we currently sign literally the module payload. For modules,
in my semi-amateurish crypto universe [1], this is fine *as long as the
key in question is used for no other purpose*. For firmware, it's
dangerous, since it would be vulnerable to substitution attacks in which
the adversary convinces us to interpret one firmware file as firmware
for another device or purpose entirely.
We should be signing something that's semantically equivalent to "This
is a valid module: xyz", "This is a valid 'regulatory.bin': xyz", or
"This is a valid kexec image: xyz".
2. Why on earth does the magic signing script reference things like
commonName? Please keep X.509 silliness as far from the kernel as possible.
3. PKCS#1 v1.5, really? PKCS#1 v1.5 is known to be insecure unless very
cafefully validated. For example:
https://www.imperialviolet.org/2014/09/26/pkcs1.html
Could we please consider using a signature scheme with a security proof?
4. As hashed to death in another thread:
http://lkml.kernel.org/g/555A88FB.7000809@kernel.org
I think that the verifier should be a dynamically loadable thing. For
an initial firmware signature verification scheme, I think that using
digital signatures is fine, though
[1] I'm sometimes a bona fide quantum cryptographer, but I'm at best a
reasonably clueful classical cryptographer wannabe.
--Andy
next prev parent reply other threads:[~2015-05-19 20:59 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-19 20:02 [RFD] linux-firmware key arrangement for firmware signing Luis R. Rodriguez
2015-05-19 20:40 ` Luis R. Rodriguez
2015-05-19 20:59 ` Andy Lutomirski [this message]
2015-05-19 22:11 ` Luis R. Rodriguez
2015-05-19 22:40 ` Andy Lutomirski
2015-05-19 23:30 ` Julian Calaby
2015-05-19 23:42 ` Andy Lutomirski
2015-05-20 0:39 ` Luis R. Rodriguez
2015-05-20 0:41 ` Andy Lutomirski
2015-05-21 22:26 ` Luis R. Rodriguez
2015-05-21 23:15 ` Casey Schaufler
2015-05-21 15:51 ` David Howells
2015-05-21 16:30 ` Mimi Zohar
2015-05-21 16:39 ` Andy Lutomirski
2015-05-21 16:51 ` Petko Manolov
2015-05-21 16:55 ` Andy Lutomirski
2015-05-21 17:44 ` Petko Manolov
2015-05-21 16:43 ` Petko Manolov
2015-05-21 16:48 ` Andy Lutomirski
2015-05-21 16:58 ` Petko Manolov
2015-05-21 16:59 ` Mimi Zohar
2015-05-19 21:48 ` Mimi Zohar
2015-05-19 22:19 ` Luis R. Rodriguez
2015-05-19 23:37 ` Mimi Zohar
2015-05-20 0:22 ` Luis R. Rodriguez
2015-05-20 1:06 ` Mimi Zohar
2015-05-20 1:29 ` Andy Lutomirski
2015-05-20 2:05 ` Mimi Zohar
2015-05-20 2:10 ` Andy Lutomirski
2015-05-20 15:49 ` Petko Manolov
2015-05-20 16:08 ` Petko Manolov
2015-05-20 14:04 ` Seth Forshee
2015-05-20 16:24 ` One Thousand Gnomes
2015-05-20 16:46 ` Petko Manolov
2015-05-21 4:41 ` Greg Kroah-Hartman
2015-05-21 5:41 ` Petko Manolov
2015-05-21 6:14 ` Greg Kroah-Hartman
2015-05-21 13:05 ` Mimi Zohar
2015-05-21 15:45 ` Greg Kroah-Hartman
2015-05-21 15:53 ` Petko Manolov
2015-05-21 16:57 ` Greg Kroah-Hartman
2015-05-26 17:08 ` One Thousand Gnomes
2015-05-26 19:15 ` Petko Manolov
2015-05-26 19:52 ` Mimi Zohar
2015-05-26 23:06 ` David Howells
2015-05-21 16:03 ` Woodhouse, David
2015-05-21 16:22 ` Mimi Zohar
2015-05-21 16:31 ` Woodhouse, David
2015-05-21 17:02 ` gregkh
2015-05-21 17:14 ` Petko Manolov
2015-05-21 18:23 ` Luis R. Rodriguez
2015-05-21 18:30 ` Luis R. Rodriguez
2015-05-21 19:32 ` Woodhouse, David
2015-05-21 17:49 ` Luis R. Rodriguez
2015-05-21 14:45 ` Petko Manolov
2015-05-21 22:50 ` Luis R. Rodriguez
2015-05-20 20:35 ` Kyle McMartin
2015-05-20 15:08 ` David Howells
2015-05-20 15:47 ` Seth Forshee
2015-05-21 16:23 ` David Howells
2015-05-20 15:14 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=555BA438.2070802@kernel.org \
--to=luto@kernel.org \
--cc=aricart@memnix.com \
--cc=bp@alien8.de \
--cc=david.woodhouse@intel.com \
--cc=dhowells@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=james.l.morris@oracle.com \
--cc=jkosina@suse.cz \
--cc=jlee@suse.de \
--cc=keyrings@linux-nfs.org \
--cc=kyle@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@suse.com \
--cc=mmarek@suse.cz \
--cc=mricon@kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=sedat.dilek@gmail.com \
--cc=serge@hallyn.com \
--cc=seth.forshee@canonical.com \
--cc=torvalds@linux-foundation.org \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).