[RFD] linux-firmware key arrangement for firmware signing

[RFD] linux-firmware key arrangement for firmware signing

[Luis R. Rodriguez]

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.

Second, it is important to understand that part of the motivation for firmware
signing comes from the fact that since the kernel already has signature
verification support for modules and that since some subsystems have *their own
solution* for cryptographic file signing checks before feeding data to the
kernel, and their own file redistribution mechanisms in place for signed files
we can simply do away with these custom subsystem solutions by just having
firmware signing capability support and using linux-firmware as a vehicle for
subsystem file redistribution. In our particular case on the 802.11 front we
have the 802.11 regulatory database regulatoy.bin that a udev helper CRDA [0]
reads before passing a regulatory domain to the kernel.  Distributions opt in
or out of having the digital signatures on the file but we recommend it
enabled, historically this was done to help enable corporate support on the
development of 802.11 drivers upstream to address regulatory considerations,
while enabling the flexibility for folks to ignore and do what they still want.
The kernel also has the ability to support bundling in firmware as built-in,
that can also help replace our own built-in reglutory db support which is
currently fragile due to it relying on some scripts for file conversion.

So for 802.11 then we have a use case where some distribution have opted in to
file signing verification support with its own mechanisms prior to the kernel
having any firmware signing support. This means that if wish to replace the
old CRDA / wireless-regdb signed redistribution mechanism we need to also
allow subsystems to opt-in to file signature requirements, so for instance
even if a kernel would not enable firmware signing in enforced mode (requiring
a valid signature otherwise not allowing the file to be passed to the kernel)
we need to allow the 802.11 subsystem to let distributions opt-in to the
same old signature requirements as before. In order to allow this flexibility
we first need kernel firmware signing support with both permissive and
enforced mode. Later we'd need to extend the firmware_class API to pass on
requirements for signatures, to enable callers to change from permissive
to enforced mode. The later aspect of this can only be added once the kernel
has signature verification support but it does mean we needed to consider how
we'd replace the signing of the regulatory.bin file and its own redistribution
mechanisms. Today Seth Forshee maintains wireless-regdb, once the db.txt ASCII
db changes Seth ends up generating a new regulatory.bin and distributions can
pick these up. Regulatory changes are not frequent.

We have discussed how we'd replace the 802.11 subsystem own regulatory.bin
redistribution and signing mechanism and decided that if the kernel gets
firmware signing support Kyle would just sign linux-firmware files within
linux-firmware itself, and Seth would send Kyle updates to the regulatory.bin
file. Distributions that would need either regulatory.bin signed and replace
CRDA can just trust Kyle's key later, and enable the option on cfg80211 to use
the firmware_class API to request the signed file. Distributions that do this
would in turn still be able to not have firmware signature enforced for all
files, they'd just have it enabled for cfg80211, in order to replace the old
CRDA / wireless-regdb signature practice.

This begs the question on how we'd manage keys for firmware signing on
linux-firmare. Since the keys are x509 keys we need a CA. Based on some initial
discussions it would seem we'd need the Linux Foundation to create a key, this
would be embedded in the kernel and that key would be used to sign Kyle's key.
Kyle would in turn use his key for signing linux-firmware files. David, Kyle,
did I summarize this correctly ?

I think we need one change here, we'd need to ensure that such key could only
be used for vetting firmware files, not modules loaded.  The firmware_class
could for instance still use all the keys in system_trusted_keyring, which
would include the UEFI key db, but it does not seems reasonable to expect keys
used for fw signing to also go into system_trusted_keyring to also be used for
module signing.

Other than this last nitpick, any other concerns or recommendations ?

[0] https://wireless.wiki.kernel.org/en/developers/regulatory/crda

  Luis

Re: [RFD] linux-firmware key arrangement for firmware signing

[Luis R. Rodriguez]

On Tue, May 19, 2015 at 1:02 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> Other than this last nitpick, any other concerns or recommendations ?

Oh one more thing. I think we should decide on a digest algorithm we'd
wish to be used for linux-firmware signing, distributions likely will
want to just have this enabled =y in their kernel unless of course
proper care is taken to also make sure such module is available early
for initramfs uses. The digest algorithm can be different than what
any distribution uses for their own module signing digest.

 Luis

Re: [RFD] linux-firmware key arrangement for firmware signing

[Andy Lutomirski]

[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

Re: [RFD] linux-firmware key arrangement for firmware signing

[Luis R. Rodriguez]

On Tue, May 19, 2015 at 01:59:36PM -0700, Andy Lutomirski wrote:
> [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*.

Indeed, that's not the only issue. For instance I recently found out that
system_trusted_keyring includes the keys under the UEFI key db, even though I
cannot see how that is done. This does ultimately mean that if MS or vendors
who have embedded keys on the UEFI key db get compromised their compromised key
can be used to sign arbitrary modules / firmware themselves. As bad as that is
I'm assured we can clear out the UEFI key db, so paranoid folks can do
that. I however do not think that this issue on trusting the keys in
the UEFI key db was readily known, or was it?.

> 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.

Agreed fully and I'm glad you bring this up. As-is with today's firmware_class
API we cannot allow custom keys if they are desired, but if we do want this we
can easily make this happen. Just let me know. With the last set of patches I
had developed my goal was to allow customizations by the callers on the key
requirements. I had this planned out because regulatory.bin used its own simple
RSA key with no x509 juju magic. I also envisioned it being easier for Kyle for
instance to use his own PGP key to sign linux-firmware files to start off with
than some complex x509 thing. Based on discussions with David, Seth, and Kyle
though it seems we were going to be happy with trusting Kyle's key for regulatory.bin,
since that will be done Kyle might as well sign all linux-firmware files and folks
who trust that can use it. If we want to override it should be easy to later.

For now then I'd be happy for us to start off with Kyle's key and
since I am adding extensions to the firmware_class API to customize
firmware signing requirements it should be fairly trivial to enable
device drivers to say they want their own firmware to be signed with
a specific key if they wanted that. I think that if we want this we
should evolve to this though as I think the complexity should be
optional.

> 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".

Sure.

> 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.

I asked the same thing. I'm hinted that Red Hat originally came up with PGP
support for module signing and then someone asked for x509 to be used.  I was
not aware of this so originally in my approach for firmware I was trying to
target regular PGP keys. In my last review of the firmware patches I asked
to see what folks preferred and it seems that the issue with supporting
PGP for firmware and PKCS#7 for modules would be that we'd have different
entry paths to support. That means complexity, etc. Another point raised
was that we can convert PGP keys to x509 with gpgpsm, so if we really
needed that we could go about it that way.

I ended up being convinced that the simplicity over sharing code path for both
module signing and firmware signing with the flexibility to be paranoid and
using one own's PGP key and doing away with all possible evil-doers certs and
practices would suffice those who do not even trust their own parents. That is
of course unless using x509 stuff alone could jeopardize PGP keys... that'd
be a big problem, of course.

> 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?

I'm fine with going with some other alternative, now what do you have in mind?
I'm in hopes David can chime in here as I'm just relying on what new thing we
end up replacing for module signing.

Ideally we want to have the option to pick and choose or just stick to one
solution which we decide we'll vet for carefully for now.

> 4. As hashed to death in another thread:

"Hashed to death" is strong for something just discussed yesterday :)

> http://lkml.kernel.org/g/555A88FB.7000809@kernel.org
> 
> I think that the verifier should be a dynamically loadable thing.

Did you just volunteeer?

> For an initial firmware signature verification scheme, I think that
> using digital signatures is fine, though

OK.

  Luis

Re: [RFD] linux-firmware key arrangement for firmware signing

[Andy Lutomirski]

On Tue, May 19, 2015 at 3:11 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Tue, May 19, 2015 at 01:59:36PM -0700, Andy Lutomirski wrote:
>> [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*.
>
> Indeed, that's not the only issue. For instance I recently found out that
> system_trusted_keyring includes the keys under the UEFI key db, even though I
> cannot see how that is done. This does ultimately mean that if MS or vendors
> who have embedded keys on the UEFI key db get compromised their compromised key
> can be used to sign arbitrary modules / firmware themselves. As bad as that is
> I'm assured we can clear out the UEFI key db, so paranoid folks can do
> that. I however do not think that this issue on trusting the keys in
> the UEFI key db was readily known, or was it?.
>
>> 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.
>
> Agreed fully and I'm glad you bring this up. As-is with today's firmware_class
> API we cannot allow custom keys if they are desired, but if we do want this we
> can easily make this happen. Just let me know. With the last set of patches I
> had developed my goal was to allow customizations by the callers on the key
> requirements. I had this planned out because regulatory.bin used its own simple
> RSA key with no x509 juju magic. I also envisioned it being easier for Kyle for
> instance to use his own PGP key to sign linux-firmware files to start off with
> than some complex x509 thing. Based on discussions with David, Seth, and Kyle
> though it seems we were going to be happy with trusting Kyle's key for regulatory.bin,
> since that will be done Kyle might as well sign all linux-firmware files and folks
> who trust that can use it. If we want to override it should be easy to later.
>
> For now then I'd be happy for us to start off with Kyle's key and
> since I am adding extensions to the firmware_class API to customize
> firmware signing requirements it should be fairly trivial to enable
> device drivers to say they want their own firmware to be signed with
> a specific key if they wanted that. I think that if we want this we
> should evolve to this though as I think the complexity should be
> optional.
>
>> 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".
>
> Sure.
>
>> 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.
>
> I asked the same thing. I'm hinted that Red Hat originally came up with PGP
> support for module signing and then someone asked for x509 to be used.  I was
> not aware of this so originally in my approach for firmware I was trying to
> target regular PGP keys. In my last review of the firmware patches I asked
> to see what folks preferred and it seems that the issue with supporting
> PGP for firmware and PKCS#7 for modules would be that we'd have different
> entry paths to support. That means complexity, etc. Another point raised
> was that we can convert PGP keys to x509 with gpgpsm, so if we really
> needed that we could go about it that way.
>
> I ended up being convinced that the simplicity over sharing code path for both
> module signing and firmware signing with the flexibility to be paranoid and
> using one own's PGP key and doing away with all possible evil-doers certs and
> practices would suffice those who do not even trust their own parents. That is
> of course unless using x509 stuff alone could jeopardize PGP keys... that'd
> be a big problem, of course.
>
>> 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?
>
> I'm fine with going with some other alternative, now what do you have in mind?
> I'm in hopes David can chime in here as I'm just relying on what new thing we
> end up replacing for module signing.

RSA-PSS, ECDSA over P-256, or Ed25519.  The IRTF CFRG is expected to
publish an RFC for a modern signature scheme any day^Wmonth^Wyear now,
too.

>
> Ideally we want to have the option to pick and choose or just stick to one
> solution which we decide we'll vet for carefully for now.
>
>> 4. As hashed to death in another thread:
>
> "Hashed to death" is strong for something just discussed yesterday :)
>
>> http://lkml.kernel.org/g/555A88FB.7000809@kernel.org
>>
>> I think that the verifier should be a dynamically loadable thing.
>
> Did you just volunteeer?

Not intentionally.  It would be easy, though.  Hmm.

Also, good point about key purposes.  Sigh, more ways that the current
system is complicated and inflexible.

--Andy

Re: [RFD] linux-firmware key arrangement for firmware signing

[David Howells]

Luis R. Rodriguez <mcgrof@suse.com> wrote:

> I had this planned out because regulatory.bin used its own simple RSA key
> with no x509 juju magic. I also envisioned it being easier for Kyle for
> instance to use his own PGP key to sign linux-firmware files to start off
> with than some complex x509 thing. Based on discussions with David, Seth,
> and Kyle though it seems we were going to be happy with trusting Kyle's key
> for regulatory.bin, since that will be done Kyle might as well sign all
> linux-firmware files and folks who trust that can use it.

To go down the signature root, what the kernel needs is:

 (1) A way to get a key into the kernel.  We're currently using X.509 for this
     for module signing and kexec.

 (2) A way to get a signature into the kernel with sufficient metadata to
     select the key to use.  Currently, kexec uses PKCS#7 for this and module
     signing uses a private format which I'm intending to change to PKCS#7.

     For firmware, I think Andy is right and we also need to include in the
     metadata something that says under what circumstances the firmware can be
     used - likely the name that is passed to request_firmware() - which must
     also be included in the digested data.

     I don't believe that module signing actually requires a hint of this type
     since we have to permit insmod to work and there won't be a hint we can
     trust.  Besides, once verified, modules have to be loadable by the module
     loader which is probably a sufficient restriction in itself.

     I don't believe that kexec signing requires a name hint either since I
     think the only restriction on what we're allowed to kexec is that it must
     be bootable from the beginning - and must be a PE binary on x86 type
     platforms.

I do have patches to parse PGP key data and add the public keys found therein
onto the kernel keyring, but that would mean adding an extra key data parser.

You could probably do this with the integrity functions - but turning them on
has a performance cost and you have to load things in the right order as I
understand it.

The hash list idea for firmware really isn't a starter for a distribution like
Fedora and especially RHEL.  We would have to crank out a new set of kernels
any time anyone released a new firmware that someone might want to load since
the hash list is effectively dependent on *all* the firmware blobs.  Further,
you cannot ever discard any entries as you would potentially prevent someone's
system from booting if you did.

> > 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?
> 
> I'm fine with going with some other alternative, now what do you have in mind?

We can look at moving to PKCS#1 v2.1 and using RSASSA-PSS.  The main
difficulty is persuading openssl that it wants to do that.

Andy Lutomirski <luto@amacapital.net> wrote:

> RSA-PSS, ECDSA over P-256, or Ed25519.  The IRTF CFRG is expected to
> publish an RFC for a modern signature scheme any day^Wmonth^Wyear now,
> too.

These are public key algorithms, not message/certificate formats, so comparing
X.509 or PKCS#7 to ECDSA or Ed25519 is not valid.

David

Re: [RFD] linux-firmware key arrangement for firmware signing

[Mimi Zohar]

On Thu, 2015-05-21 at 16:51 +0100, David Howells wrote:
> Luis R. Rodriguez <mcgrof@suse.com> wrote:
> 
> > I had this planned out because regulatory.bin used its own simple RSA key
> > with no x509 juju magic. I also envisioned it being easier for Kyle for
> > instance to use his own PGP key to sign linux-firmware files to start off
> > with than some complex x509 thing. Based on discussions with David, Seth,
> > and Kyle though it seems we were going to be happy with trusting Kyle's key
> > for regulatory.bin, since that will be done Kyle might as well sign all
> > linux-firmware files and folks who trust that can use it.
> 
> To go down the signature root, what the kernel needs is:
> 
>  (1) A way to get a key into the kernel.  We're currently using X.509 for this
>      for module signing and kexec.
> 
>  (2) A way to get a signature into the kernel with sufficient metadata to
>      select the key to use.  Currently, kexec uses PKCS#7 for this and module
>      signing uses a private format which I'm intending to change to PKCS#7.
> 
>      For firmware, I think Andy is right and we also need to include in the
>      metadata something that says under what circumstances the firmware can be
>      used - likely the name that is passed to request_firmware() - which must
>      also be included in the digested data.
> 
>      I don't believe that module signing actually requires a hint of this type
>      since we have to permit insmod to work and there won't be a hint we can
>      trust.  Besides, once verified, modules have to be loadable by the module
>      loader which is probably a sufficient restriction in itself.
> 
>      I don't believe that kexec signing requires a name hint either since I
>      think the only restriction on what we're allowed to kexec is that it must
>      be bootable from the beginning - and must be a PE binary on x86 type
>      platforms.
> 
> I do have patches to parse PGP key data and add the public keys found therein
> onto the kernel keyring, but that would mean adding an extra key data parser.
> 
> You could probably do this with the integrity functions - but turning them on
> has a performance cost and you have to load things in the right order as I
> understand it.

The only ordering is loading the keys before verifying the signatures.
Have you recently done any performance testing?

Mimi

Re: [RFD] linux-firmware key arrangement for firmware signing

[Andy Lutomirski]

On May 21, 2015 8:52 AM, "David Howells" <dhowells@redhat.com> wrote:
>
> Luis R. Rodriguez <mcgrof@suse.com> wrote:
>
> > I had this planned out because regulatory.bin used its own simple RSA key
> > with no x509 juju magic. I also envisioned it being easier for Kyle for
> > instance to use his own PGP key to sign linux-firmware files to start off
> > with than some complex x509 thing. Based on discussions with David, Seth,
> > and Kyle though it seems we were going to be happy with trusting Kyle's key
> > for regulatory.bin, since that will be done Kyle might as well sign all
> > linux-firmware files and folks who trust that can use it.
>
> To go down the signature root, what the kernel needs is:
>
>  (1) A way to get a key into the kernel.  We're currently using X.509 for this
>      for module signing and kexec.
>
>  (2) A way to get a signature into the kernel with sufficient metadata to
>      select the key to use.  Currently, kexec uses PKCS#7 for this and module
>      signing uses a private format which I'm intending to change to PKCS#7.

I think PKCS#7 doesn't even solve the problem we actually need to
solve, which is that we want to trust the wireless regulatory key for
regulatory.bin but nothing else.  Keep in mind that every attempt to
do this for web CAs using X.509 has failed miserably (Google "name
constraints"), whereas having a trivial set if flags associated with
any key format whatsoever in the kernel would solve it fully.

Just track a list of allowed purposes for each key.  If we really
really need cert chains, restrict the child to be a subset of the
parent, which is something that X.509 thoroughly screwed up.

>
>      For firmware, I think Andy is right and we also need to include in the
>      metadata something that says under what circumstances the firmware can be
>      used - likely the name that is passed to request_firmware() - which must
>      also be included in the digested data.
>
>      I don't believe that module signing actually requires a hint of this type
>      since we have to permit insmod to work and there won't be a hint we can
>      trust.  Besides, once verified, modules have to be loadable by the module
>      loader which is probably a sufficient restriction in itself.
>

Famous last words: "Is probably a sufficient restriction".  Let the
crypto do its job -- the bad guys are almost certainly more clever
than the module loader.

I think that we neither can nor should check the module name against a
tag -- the module name is part of the signed module payload.

>      I don't believe that kexec signing requires a name hint either since I
>      think the only restriction on what we're allowed to kexec is that it must
>      be bootable from the beginning - and must be a PE binary on x86 type
>      platforms.
>
> I do have patches to parse PGP key data and add the public keys found therein
> onto the kernel keyring, but that would mean adding an extra key data parser.

Why would this have to live in the kernel?  If you want to add a key
to the keyring, feed the raw key to the keyring along with some reason
to trust the key.  There's no need to stick OpenPGP in the kernel.

I think we're all (except maybe Luis) too stuck on key/cert formats.
Kyle wants to use OpenPGP.  You want to use PKCS#7.  Some people want
to use PKCS#11 with whatever wrapper.  Probably someone out there
wants to use the SSH infrastructure.  Who cares?  As long as we keep
using PKCS#1 v1.5 as the underlying technology, all of these are
exactly equivalent.

Some day soon we should move away from PKCS#1 v1.5 as our preferred
technology, at which point either we still support it for legacy
purposes or we have to update the tooling.  But I really think that
the tooling should be just that: tooling.

The single reasonably exception I've heard is that we need to support
Authenticode for kexec.  I don't really believe that entirely --
surely we can produce a kernel image that is both validly signed using
Authenticode *and* validly signed with our internal format.  Or we can
have a separate special-case parser for Authenticode-signed kexec
images and we can turn it off for users who don't want it (which
presumably includes everyone using things like Quark, which is a
bizarre architecture that is extremely memory-constrained but
nonetheless supports Secure Boot).

>
> You could probably do this with the integrity functions - but turning them on
> has a performance cost and you have to load things in the right order as I
> understand it.

It's also a performance cost because the average user of this
signature stuff doesn't actually want IMA, and IMA is checking the
wrong think anyway.  IMA/EVM tells us "this file validly belongs in
/lib/modules/whatever according to whomever we trust for the
filesystem".  We want to check "is this data, regardless of where it
was read from, a trusted module".

>
> The hash list idea for firmware really isn't a starter for a distribution like
> Fedora and especially RHEL.  We would have to crank out a new set of kernels
> any time anyone released a new firmware that someone might want to load since
> the hash list is effectively dependent on *all* the firmware blobs.  Further,
> you cannot ever discard any entries as you would potentially prevent someone's
> system from booting if you did.

Can we please stop beating this dead horse?  AFAIK no one ever
suggested using a has list for firmware in the first place.

>
> > > 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?
> >
> > I'm fine with going with some other alternative, now what do you have in mind?
>
> We can look at moving to PKCS#1 v2.1 and using RSASSA-PSS.  The main
> difficulty is persuading openssl that it wants to do that.
>

openssl pkeyutl appears to support PSS.

> Andy Lutomirski <luto@amacapital.net> wrote:
>
> > RSA-PSS, ECDSA over P-256, or Ed25519.  The IRTF CFRG is expected to
> > publish an RFC for a modern signature scheme any day^Wmonth^Wyear now,
> > too.
>
> These are public key algorithms, not message/certificate formats, so comparing
> X.509 or PKCS#7 to ECDSA or Ed25519 is not valid.

Sure it is, because we don't actually seem to need a fancy
message/certificate format in the first place.

--Andy

Re: [RFD] linux-firmware key arrangement for firmware signing

[Petko Manolov]

On 15-05-21 09:39:50, Andy Lutomirski wrote:
> 
> It's also a performance cost because the average user of this signature stuff 
> doesn't actually want IMA, and IMA is checking the wrong think anyway.  
> IMA/EVM tells us "this file validly belongs in /lib/modules/whatever according 
> to whomever we trust for the filesystem".  We want to check "is this data, 
> regardless of where it was read from, a trusted module".

IMA-appraise does not care where the file comes from (although it may be 
persuaded to) and verifies file's data and meta-data against a signature.  I 
guess you should actually read the code. :)


		Petko

Re: [RFD] linux-firmware key arrangement for firmware signing

[Andy Lutomirski]

On Thu, May 21, 2015 at 9:51 AM, Petko Manolov <petkan@mip-labs.com> wrote:
> On 15-05-21 09:39:50, Andy Lutomirski wrote:
>>
>> It's also a performance cost because the average user of this signature stuff
>> doesn't actually want IMA, and IMA is checking the wrong think anyway.
>> IMA/EVM tells us "this file validly belongs in /lib/modules/whatever according
>> to whomever we trust for the filesystem".  We want to check "is this data,
>> regardless of where it was read from, a trusted module".
>
> IMA-appraise does not care where the file comes from (although it may be
> persuaded to) and verifies file's data and meta-data against a signature.  I
> guess you should actually read the code. :)
>

I read plenty of the code.  I said "data" not "file" for a reason.
I'll quote some code:

int ima_appraise_measurement(int func, struct integrity_iint_cache *iint,
                             struct file *file, const unsigned char *filename,
                             struct evm_ima_xattr_data *xattr_value,
                             int xattr_len, int opened)

There is no struct file in init_module.

{
        static const char op[] = "appraise_data";
        char *cause = "unknown";
        struct dentry *dentry = file->f_path.dentry;
        struct inode *inode = dentry->d_inode;
        enum integrity_status status = INTEGRITY_UNKNOWN;
        int rc = xattr_len, hash_start = 0;

        if (!inode->i_op->getxattr)
                return INTEGRITY_UNKNOWN;

Even for finit_module, which does have a struct file, there is
absolutely no reason to require that the file's inode has a getxattr
operation.

I maintain my claim that IMA is not appropriate for module signing in
general.  It might make sense for the kind of thing that Chromium does
(approving of modules using finit_module based on their source instead
of their payload and verifying the payload indirectly using IMA or
dm-verity), but that's not the problem that David and Luis are trying
to solve.

Also, especially for firmware on regular distros, IMA is ridiculous.
IIRC there is no general support for xattrs in initramfs, and there is
no reason to start requiring such support just to allow firmware to
live in initramfs.

I think that using IMA for this has a similar problem to using PKCS#7:
it's a big hammer that is much more complex than necessary to solve
the problem at hand.

--Andy

Re: [RFD] linux-firmware key arrangement for firmware signing

[Petko Manolov]

On 15-05-21 09:55:42, Andy Lutomirski wrote:
> 
> I read plenty of the code.  I said "data" not "file" for a reason.
> I'll quote some code:
> 
> int ima_appraise_measurement(int func, struct integrity_iint_cache *iint,
>                              struct file *file, const unsigned char *filename,
>                              struct evm_ima_xattr_data *xattr_value,
>                              int xattr_len, int opened)
> 
> There is no struct file in init_module.
> 
> {
>         static const char op[] = "appraise_data";
>         char *cause = "unknown";
>         struct dentry *dentry = file->f_path.dentry;
>         struct inode *inode = dentry->d_inode;
>         enum integrity_status status = INTEGRITY_UNKNOWN;
>         int rc = xattr_len, hash_start = 0;
> 
>         if (!inode->i_op->getxattr)
>                 return INTEGRITY_UNKNOWN;

Yes, not all filesystems support extended attributes, but this is not 
necessarily end of the game.  IMA code may be modified to use detached 
signatures.  In fact i was considering this option not so long ago, but dropped 
the idea as more elegant solution was presented.

> I maintain my claim that IMA is not appropriate for module signing in general.  
> It might make sense for the kind of thing that Chromium does (approving of 
> modules using finit_module based on their source instead of their payload and 
> verifying the payload indirectly using IMA or dm-verity), but that's not the 
> problem that David and Luis are trying to solve.

I guess this is all backwards.  Module signing/verification must be autonomous 
process/infrastructure.  The fact that IMA may do the same for you given a few 
conditions are met does not make it a replacement.

I do not use module signing for one particular project, because we're building 
custom kernel and initramfs.  IMA is enabled early on so an attempt to read .ko 
file results in verifying it's signature.  Yes, the filesystem does support 
xattr. :)

> Also, especially for firmware on regular distros, IMA is ridiculous. IIRC 
> there is no general support for xattrs in initramfs, and there is no reason to 
> start requiring such support just to allow firmware to live in initramfs.

For regular distro, maybe.  If one needs better overall security - not so - i 
actually quite like IMA. ;) Adding xattrs to initramfs is not bad idea at all, 
IMA arguments aside.

> I think that using IMA for this has a similar problem to using PKCS#7: it's a 
> big hammer that is much more complex than necessary to solve the problem at 
> hand.

Absolutely.  Using IMA just for module signing is a bit of an overkill.


		Petko

Re: [RFD] linux-firmware key arrangement for firmware signing

[Petko Manolov]

On 15-05-21 16:51:49, David Howells wrote:
> 
> I do have patches to parse PGP key data and add the public keys found therein
> onto the kernel keyring, but that would mean adding an extra key data parser.

PGP is widely used so i would gladly have one more parser in the kernel.

> You could probably do this with the integrity functions - but turning them on 
> has a performance cost and you have to load things in the right order as I 
> understand it.

The performance hit is negligible, especially on modern hardware.  The problem 
is that Joe user must wrap his head around IMA as a concept and go through the 
pains of doing everything right.  Failing to do so will result in a lot of 
frustration, and i speak from experience.

Once you make it run properly it mostly stays out of your way.  To put it 
another way: IMA is not for sissies... :)


		Petko

Re: [RFD] linux-firmware key arrangement for firmware signing

[Andy Lutomirski]

On Thu, May 21, 2015 at 9:43 AM, Petko Manolov <petkan@mip-labs.com> wrote:
> On 15-05-21 16:51:49, David Howells wrote:
>>
>> I do have patches to parse PGP key data and add the public keys found therein
>> onto the kernel keyring, but that would mean adding an extra key data parser.
>
> PGP is widely used so i would gladly have one more parser in the kernel.

<rant>
PGP is also a crappy format:

http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html

and using PGP means we're probably stuck with PKCS#1 v1.5, which
should have been phased out worldwide many years ago.

In any event, I don't see why PGP compatibility requires any sort of
OpenPGP parser in the kernel.  Just because GnuPG goes out of its way
to be incompatible with anything other than the OpenPGP ecosystem
doesn't mean that you can't relatively straightforwardly generate raw
PKCS#1 signatures from an OpenPGP key.
</rant>

Re: [RFD] linux-firmware key arrangement for firmware signing

[Petko Manolov]

On 15-05-21 09:48:10, Andy Lutomirski wrote:
> On Thu, May 21, 2015 at 9:43 AM, Petko Manolov <petkan@mip-labs.com> wrote:
> > On 15-05-21 16:51:49, David Howells wrote:
> >>
> >> I do have patches to parse PGP key data and add the public keys found therein
> >> onto the kernel keyring, but that would mean adding an extra key data parser.
> >
> > PGP is widely used so i would gladly have one more parser in the kernel.
> 
> <rant>
> PGP is also a crappy format:
> 
> http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html
> 
> and using PGP means we're probably stuck with PKCS#1 v1.5, which should have 
> been phased out worldwide many years ago.
> 
> In any event, I don't see why PGP compatibility requires any sort of
> OpenPGP parser in the kernel.  Just because GnuPG goes out of its way
> to be incompatible with anything other than the OpenPGP ecosystem
> doesn't mean that you can't relatively straightforwardly generate raw
> PKCS#1 signatures from an OpenPGP key.
> </rant>

Oh, i do agree with you in terms of quality of both formats.  However, this is 
what is commonly used these days and not having these parsers in the kernel 
would require us to write tools for conversion to saner format.  Which does not 
exist for the moment.  Once we have those in place it would be all the same to 
me.


		Petko

Re: [RFD] linux-firmware key arrangement for firmware signing

[Mimi Zohar]

On Thu, 2015-05-21 at 19:43 +0300, Petko Manolov wrote:
> On 15-05-21 16:51:49, David Howells wrote:
> > 
> > I do have patches to parse PGP key data and add the public keys found therein
> > onto the kernel keyring, but that would mean adding an extra key data parser.
> 
> PGP is widely used so i would gladly have one more parser in the kernel.
> 
> > You could probably do this with the integrity functions - but turning them on 
> > has a performance cost and you have to load things in the right order as I 
> > understand it.
> 
> The performance hit is negligible, especially on modern hardware.  The problem 
> is that Joe user must wrap his head around IMA as a concept and go through the 
> pains of doing everything right.  Failing to do so will result in a lot of 
> frustration, and i speak from experience.
> 
> Once you make it run properly it mostly stays out of your way.  To put it 
> another way: IMA is not for sissies... :)

The main problem today is that software doesn't come and isn't installed
with file signatures.   Once file signatures are installed with the
files,  then it is just a matter of the machine owner signing the
software's public keys.   Dracut (or equivalent) would load the signed
keys onto the trusted IMA keyring.

Mimi

Re: [RFD] linux-firmware key arrangement for firmware signing

[Julian Calaby]

Hi All,

On Wed, May 20, 2015 at 6:59 AM, Andy Lutomirski <luto@kernel.org> wrote:
> [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".

Something that occurred to me (as a complete bystander) was: would it
make sense to have keys able to be restricted to particular "types" of
signable data? I.e. the key that can sign a valid regulatory.bin file
cannot be used to sign a module or a kexec image. - This could remove
the need to have multiple keyrings. (Also, UEFI keys unless otherwise
tagged could be restricted to only signing bootloaders or kernels)

Also, are multiple signatures a sensible thing? E.g. regulatory.bin
gets signed by Seth, then Kyle, then $DISTRO and any one key is enough
to validate it.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [RFD] linux-firmware key arrangement for firmware signing

[Andy Lutomirski]

On Tue, May 19, 2015 at 4:30 PM, Julian Calaby <julian.calaby@gmail.com> wrote:
> Hi All,
>
> On Wed, May 20, 2015 at 6:59 AM, Andy Lutomirski <luto@kernel.org> wrote:
>> [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".
>
> Something that occurred to me (as a complete bystander) was: would it
> make sense to have keys able to be restricted to particular "types" of
> signable data? I.e. the key that can sign a valid regulatory.bin file
> cannot be used to sign a module or a kexec image. - This could remove
> the need to have multiple keyrings. (Also, UEFI keys unless otherwise
> tagged could be restricted to only signing bootloaders or kernels)

Seems sensible to me.

FWIW, I'm starting to think that UEFI-based validation of kexec images
should be totally separate.  It uses a nasty PE format with a hideous
PKCS #7 formatted signature.  Maybe that should be a completely
separate piece of code.

>
> Also, are multiple signatures a sensible thing? E.g. regulatory.bin
> gets signed by Seth, then Kyle, then $DISTRO and any one key is enough
> to validate it.

That might further complicate matters.

--Andy

Re: [RFD] linux-firmware key arrangement for firmware signing

[Luis R. Rodriguez]

On Tue, May 19, 2015 at 04:42:05PM -0700, Andy Lutomirski wrote:
> On Tue, May 19, 2015 at 4:30 PM, Julian Calaby <julian.calaby@gmail.com> wrote:
> > Hi All,
> >
> > On Wed, May 20, 2015 at 6:59 AM, Andy Lutomirski <luto@kernel.org> wrote:
> >> [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".
> >
> > Something that occurred to me (as a complete bystander) was: would it
> > make sense to have keys able to be restricted to particular "types" of
> > signable data? I.e. the key that can sign a valid regulatory.bin file
> > cannot be used to sign a module or a kexec image. - This could remove
> > the need to have multiple keyrings. (Also, UEFI keys unless otherwise
> > tagged could be restricted to only signing bootloaders or kernels)
> 
> Seems sensible to me.

As for having keys for fw signing be specific to fw data without a keyring,
if that is desirable I think we can devise a way to do that. For instance
if we wanted to we can have FW_SIG by default trust first keys on
system_trusted_keyring just as module signature works -- or if we wanted to
just trust, say a Kyle key. Not sure if the later is possible yet, but htat
would require some changes. Then as an evolution if we wanted to enable a
specific request fw to be mapped to a specific fw file the new APIs I was
looking to add could easily enable this provided that we first decide we
do want to trust say one key perhaps not on system_trusted_keyring for fw
signing. That'd need to be decided first.

As for the UEFI stuff -- from what I gather its too late there. We could
certainly go with something else for fw signing though, just lemme hear it
hard and clear.

> FWIW, I'm starting to think that UEFI-based validation of kexec images
> should be totally separate.  It uses a nasty PE format with a hideous
> PKCS #7 formatted signature.  Maybe that should be a completely
> separate piece of code.

LSM'ify it I guess? Again, if that's reasonable then I think we'll need
stacking and that's still not merged.

  Luis

Re: [RFD] linux-firmware key arrangement for firmware signing

[Andy Lutomirski]

On Tue, May 19, 2015 at 5:39 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Tue, May 19, 2015 at 04:42:05PM -0700, Andy Lutomirski wrote:
>> On Tue, May 19, 2015 at 4:30 PM, Julian Calaby <julian.calaby@gmail.com> wrote:
>> > Hi All,
>> >
>> > On Wed, May 20, 2015 at 6:59 AM, Andy Lutomirski <luto@kernel.org> wrote:
>> >> [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".
>> >
>> > Something that occurred to me (as a complete bystander) was: would it
>> > make sense to have keys able to be restricted to particular "types" of
>> > signable data? I.e. the key that can sign a valid regulatory.bin file
>> > cannot be used to sign a module or a kexec image. - This could remove
>> > the need to have multiple keyrings. (Also, UEFI keys unless otherwise
>> > tagged could be restricted to only signing bootloaders or kernels)
>>
>> Seems sensible to me.
>
> As for having keys for fw signing be specific to fw data without a keyring,
> if that is desirable I think we can devise a way to do that. For instance
> if we wanted to we can have FW_SIG by default trust first keys on
> system_trusted_keyring just as module signature works -- or if we wanted to
> just trust, say a Kyle key. Not sure if the later is possible yet, but htat
> would require some changes. Then as an evolution if we wanted to enable a
> specific request fw to be mapped to a specific fw file the new APIs I was
> looking to add could easily enable this provided that we first decide we
> do want to trust say one key perhaps not on system_trusted_keyring for fw
> signing. That'd need to be decided first.
>
> As for the UEFI stuff -- from what I gather its too late there. We could
> certainly go with something else for fw signing though, just lemme hear it
> hard and clear.
>
>> FWIW, I'm starting to think that UEFI-based validation of kexec images
>> should be totally separate.  It uses a nasty PE format with a hideous
>> PKCS #7 formatted signature.  Maybe that should be a completely
>> separate piece of code.
>
> LSM'ify it I guess? Again, if that's reasonable then I think we'll need
> stacking and that's still not merged.

Isn't stacking backwards for this, though?  The semantics we'd want is
accept if any verifiers accept, not accept if all verifiers accept,
right?

--Andy

Re: [RFD] linux-firmware key arrangement for firmware signing

[Luis R. Rodriguez]

On Tue, May 19, 2015 at 05:41:37PM -0700, Andy Lutomirski wrote:
> On Tue, May 19, 2015 at 5:39 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> > On Tue, May 19, 2015 at 04:42:05PM -0700, Andy Lutomirski wrote:
> >> On Tue, May 19, 2015 at 4:30 PM, Julian Calaby <julian.calaby@gmail.com> wrote:
> >> > Hi All,
> >> >
> >> > On Wed, May 20, 2015 at 6:59 AM, Andy Lutomirski <luto@kernel.org> wrote:
> >> >> [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".
> >> >
> >> > Something that occurred to me (as a complete bystander) was: would it
> >> > make sense to have keys able to be restricted to particular "types" of
> >> > signable data? I.e. the key that can sign a valid regulatory.bin file
> >> > cannot be used to sign a module or a kexec image. - This could remove
> >> > the need to have multiple keyrings. (Also, UEFI keys unless otherwise
> >> > tagged could be restricted to only signing bootloaders or kernels)
> >>
> >> Seems sensible to me.
> >
> > As for having keys for fw signing be specific to fw data without a keyring,
> > if that is desirable I think we can devise a way to do that. For instance
> > if we wanted to we can have FW_SIG by default trust first keys on
> > system_trusted_keyring just as module signature works -- or if we wanted to
> > just trust, say a Kyle key. Not sure if the later is possible yet, but htat
> > would require some changes. Then as an evolution if we wanted to enable a
> > specific request fw to be mapped to a specific fw file the new APIs I was
> > looking to add could easily enable this provided that we first decide we
> > do want to trust say one key perhaps not on system_trusted_keyring for fw
> > signing. That'd need to be decided first.
> >
> > As for the UEFI stuff -- from what I gather its too late there. We could
> > certainly go with something else for fw signing though, just lemme hear it
> > hard and clear.
> >
> >> FWIW, I'm starting to think that UEFI-based validation of kexec images
> >> should be totally separate.  It uses a nasty PE format with a hideous
> >> PKCS #7 formatted signature.  Maybe that should be a completely
> >> separate piece of code.
> >
> > LSM'ify it I guess? Again, if that's reasonable then I think we'll need
> > stacking and that's still not merged.
> 
> Isn't stacking backwards for this, though?  The semantics we'd want is
> accept if any verifiers accept, not accept if all verifiers accept,
> right?

That can be added, and if stacking is not yet merged perhaps Casey can
consider it?

  Luis

Re: [RFD] linux-firmware key arrangement for firmware signing

[Casey Schaufler]

On 5/21/2015 3:26 PM, Luis R. Rodriguez wrote:
> On Tue, May 19, 2015 at 05:41:37PM -0700, Andy Lutomirski wrote:
>> On Tue, May 19, 2015 at 5:39 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
>>> On Tue, May 19, 2015 at 04:42:05PM -0700, Andy Lutomirski wrote:
>>>> On Tue, May 19, 2015 at 4:30 PM, Julian Calaby <julian.calaby@gmail.com> wrote:
>>>>> Hi All,
>>>>>
>>>>> On Wed, May 20, 2015 at 6:59 AM, Andy Lutomirski <luto@kernel.org> wrote:
>>>>>> [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".
>>>>> Something that occurred to me (as a complete bystander) was: would it
>>>>> make sense to have keys able to be restricted to particular "types" of
>>>>> signable data? I.e. the key that can sign a valid regulatory.bin file
>>>>> cannot be used to sign a module or a kexec image. - This could remove
>>>>> the need to have multiple keyrings. (Also, UEFI keys unless otherwise
>>>>> tagged could be restricted to only signing bootloaders or kernels)
>>>> Seems sensible to me.
>>> As for having keys for fw signing be specific to fw data without a keyring,
>>> if that is desirable I think we can devise a way to do that. For instance
>>> if we wanted to we can have FW_SIG by default trust first keys on
>>> system_trusted_keyring just as module signature works -- or if we wanted to
>>> just trust, say a Kyle key. Not sure if the later is possible yet, but htat
>>> would require some changes. Then as an evolution if we wanted to enable a
>>> specific request fw to be mapped to a specific fw file the new APIs I was
>>> looking to add could easily enable this provided that we first decide we
>>> do want to trust say one key perhaps not on system_trusted_keyring for fw
>>> signing. That'd need to be decided first.
>>>
>>> As for the UEFI stuff -- from what I gather its too late there. We could
>>> certainly go with something else for fw signing though, just lemme hear it
>>> hard and clear.
>>>
>>>> FWIW, I'm starting to think that UEFI-based validation of kexec images
>>>> should be totally separate.  It uses a nasty PE format with a hideous
>>>> PKCS #7 formatted signature.  Maybe that should be a completely
>>>> separate piece of code.
>>> LSM'ify it I guess? Again, if that's reasonable then I think we'll need
>>> stacking and that's still not merged.
>> Isn't stacking backwards for this, though?  The semantics we'd want is
>> accept if any verifiers accept, not accept if all verifiers accept,
>> right?
> That can be added, and if stacking is not yet merged perhaps Casey can
> consider it?

So long as the net result coming out of an module is a yes/no answer,
and so long as you're not using any of the security blobs there's no
reason you can't stack exactly like Yama. Within your module you can
enforce an aggressive grant policy if you like, returning -EACCES only
if all your verifiers fail.


>
>   Luis
>

Re: [RFD] linux-firmware key arrangement for firmware signing

[Mimi Zohar]

On Tue, 2015-05-19 at 22:02 +0200, 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.

Commit 13752fe "security: introduce kernel_fw_from_file hook" introduced
a new security hook.  (IMA is on this hook as well.)  Have you
considered using this hook?
Are there other places that this hook would need to be called?

> I think we need one change here, we'd need to ensure that such key could only
> be used for vetting firmware files, not modules loaded.  The firmware_class
> could for instance still use all the keys in system_trusted_keyring, which
> would include the UEFI key db, but it does not seems reasonable to expect keys
> used for fw signing to also go into system_trusted_keyring to also be used for
> module signing.

I agree totally!  For this reason, IMA defined a separate trusted
keyring to be used for verifying file signatures.

Mimi

> Other than this last nitpick, any other concerns or recommendations ?
> 
> [0] https://wireless.wiki.kernel.org/en/developers/regulatory/crda
> 
>   Luis

Re: [RFD] linux-firmware key arrangement for firmware signing

[Luis R. Rodriguez]

On Tue, May 19, 2015 at 05:48:37PM -0400, Mimi Zohar wrote:
> On Tue, 2015-05-19 at 22:02 +0200, 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.
> 
> Commit 13752fe "security: introduce kernel_fw_from_file hook" introduced
> a new security hook.  (IMA is on this hook as well.)  Have you
> considered using this hook?

Yes, the same hook is used here.

> Are there other places that this hook would need to be called?

Nope, it'd be called. Folks who do not want to use key signing stuff can use
their own preferred LSM hook just as module signing has the kernel module
signing infrastructure but also module LSM hooks. It'd be similar here for
firmware.

Now that we have LSM hooks stacked on the way perhaps this is more in line with
what Andy has envisioned for alternatives for module signature verification.
But then again since an LSM hook already exists for both modules and firmware
perhaps this is sufficient for what Andy envisions? That is if folks do not want
this signing thing just disable it and add use your preferred LSM module of choice?

Now granted -- if we envision this module signing infrastructure as an LSM hook
in and of itself perhaps we should LSM'ify it. Its not right now.

> > I think we need one change here, we'd need to ensure that such key could only
> > be used for vetting firmware files, not modules loaded.  The firmware_class
> > could for instance still use all the keys in system_trusted_keyring, which
> > would include the UEFI key db, but it does not seems reasonable to expect keys
> > used for fw signing to also go into system_trusted_keyring to also be used for
> > module signing.
> 
> I agree totally!  For this reason, IMA defined a separate trusted
> keyring to be used for verifying file signatures.

OK I'll add that to my TODO list here.

  Luis

Re: [RFD] linux-firmware key arrangement for firmware signing

[Mimi Zohar]

On Wed, 2015-05-20 at 00:19 +0200, Luis R. Rodriguez wrote:
> On Tue, May 19, 2015 at 05:48:37PM -0400, Mimi Zohar wrote:
> > On Tue, 2015-05-19 at 22:02 +0200, 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.
> > 
> > Commit 13752fe "security: introduce kernel_fw_from_file hook" introduced
> > a new security hook.  (IMA is on this hook as well.)  Have you
> > considered using this hook?
> 
> Yes, the same hook is used here.
> 
> > Are there other places that this hook would need to be called?
> 
> Nope, it'd be called. Folks who do not want to use key signing stuff can use
> their own preferred LSM hook just as module signing has the kernel module
> signing infrastructure but also module LSM hooks. It'd be similar here for
> firmware.

When the kernel module signing signature verification was upstreamed,
Rusty was not aware of IMA-appraisal -
https://lkml.org/lkml/2013/1/22/20  In this case, not only is there a
security hook, but the IMA hook exists as well.  To appraise firmware,
add a line to the IMA policy containing "appraise func=FIRMWARE_CHECK".
Similarly, to add a measurement to the measurement list, add a line to
the IMA policy containing "measure func=FIRMWAE_CHECK". 

> Now that we have LSM hooks stacked on the way perhaps this is more in line with
> what Andy has envisioned for alternatives for module signature verification.
> But then again since an LSM hook already exists for both modules and firmware
> perhaps this is sufficient for what Andy envisions? That is if folks do not want
> this signing thing just disable it and add use your preferred LSM module of choice?
> 
> Now granted -- if we envision this module signing infrastructure as an LSM hook
> in and of itself perhaps we should LSM'ify it. Its not right now.
> 
> > > I think we need one change here, we'd need to ensure that such key could only
> > > be used for vetting firmware files, not modules loaded.  The firmware_class
> > > could for instance still use all the keys in system_trusted_keyring, which
> > > would include the UEFI key db, but it does not seems reasonable to expect keys
> > > used for fw signing to also go into system_trusted_keyring to also be used for
> > > module signing.
> > 
> > I agree totally!  For this reason, IMA defined a separate trusted
> > keyring to be used for verifying file signatures.
> 
> OK I'll add that to my TODO list here.

You'll probably want to create a new trusted firmware keyring.   By
trusted, only signed keys by a key on the system_keyring can be added to
the.ima keyring.  Using the "ca_keys" boot command line option a
specific key on the system keyring can be specified.

Mimi

Re: [RFD] linux-firmware key arrangement for firmware signing

[Luis R. Rodriguez]

On Tue, May 19, 2015 at 4:37 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Wed, 2015-05-20 at 00:19 +0200, Luis R. Rodriguez wrote:
>> On Tue, May 19, 2015 at 05:48:37PM -0400, Mimi Zohar wrote:
>> > On Tue, 2015-05-19 at 22:02 +0200, 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.
>> >
>> > Commit 13752fe "security: introduce kernel_fw_from_file hook" introduced
>> > a new security hook.  (IMA is on this hook as well.)  Have you
>> > considered using this hook?
>>
>> Yes, the same hook is used here.
>>
>> > Are there other places that this hook would need to be called?
>>
>> Nope, it'd be called. Folks who do not want to use key signing stuff can use
>> their own preferred LSM hook just as module signing has the kernel module
>> signing infrastructure but also module LSM hooks. It'd be similar here for
>> firmware.
>
> When the kernel module signing signature verification was upstreamed,
> Rusty was not aware of IMA-appraisal -
> https://lkml.org/lkml/2013/1/22/20

Rusty also just told David that PKCS#7 support changes do not need his
Acked-by and do not need to go through his tree as they do not touch
module.[ch]:

https://lkml.org/lkml/2015/5/15/865

So -- your quote does not mean that  module signature code moving to
PKCS#7 will not go in to the kernel. If you'd like to chime in on that
topic I suggest you express your concerns there on that ongoing
thread.

> In this case, not only is there a
> security hook, but the IMA hook exists as well.  To appraise firmware,
> add a line to the IMA policy containing "appraise func=FIRMWARE_CHECK".
> Similarly, to add a measurement to the measurement list, add a line to
> the IMA policy containing "measure func=FIRMWAE_CHECK".

I have a series of reasons find IMA unsuitable for the current goals at hand:

  1) IMA is a pretty big kitchen sink, we want this to work well for
even embedded systems, or architectures that do not have or require
TPMs
  2) The appraisal is also done for to account for a specific state of
affairs, you appraise to the user of the integrity of the system at a
specific point in time, firmware signing can provide integrity /
authorship vetting of files directly from the authors. In the case of
regulatory.bin that was the whole point of it, and firmware signing as
is being provided is intended to generalize that but by sharing code
in-kernel with module signing infrastructure

I am in hopes some others might be able to chime in more on point 2) here.

Don't get me wrong IMA is nice, but its a big chunky requirement to
have, more than what module signing provides and what it requires
today to replace subsystem file signing requirements.

Now, LSM hooks -- that's more aligned with something we can start IMHO
reasonably arguing we should shift module signing code to be punted
into. But I've heard stories of LSM having issues with some virtual
environments, and LSM stacking is also pretty new, and IMHO that'd be
one way to compartmentalize all this module signing code. IMHO that
*should happen* but can only be taken seriously once LSM stacking is
merged in and baked. Its not, but I'm excited for it.

>> Now that we have LSM hooks stacked on the way perhaps this is more in line with
>> what Andy has envisioned for alternatives for module signature verification.
>> But then again since an LSM hook already exists for both modules and firmware
>> perhaps this is sufficient for what Andy envisions? That is if folks do not want
>> this signing thing just disable it and add use your preferred LSM module of choice?
>>
>> Now granted -- if we envision this module signing infrastructure as an LSM hook
>> in and of itself perhaps we should LSM'ify it. Its not right now.
>>
>> > > I think we need one change here, we'd need to ensure that such key could only
>> > > be used for vetting firmware files, not modules loaded.  The firmware_class
>> > > could for instance still use all the keys in system_trusted_keyring, which
>> > > would include the UEFI key db, but it does not seems reasonable to expect keys
>> > > used for fw signing to also go into system_trusted_keyring to also be used for
>> > > module signing.
>> >
>> > I agree totally!  For this reason, IMA defined a separate trusted
>> > keyring to be used for verifying file signatures.
>>
>> OK I'll add that to my TODO list here.
>
> You'll probably want to create a new trusted firmware keyring.

Sure

>  By trusted, only signed keys by a key on the system_keyring can be added to
> the.ima keyring.

If we go with IMA, I however do not think this would be appropriate
and overkill at this point in time.

> Using the "ca_keys" boot command line option a specific key on the system keyring can be specified.

Likewise.

 Luis

Re: [RFD] linux-firmware key arrangement for firmware signing

[Mimi Zohar]

On Tue, 2015-05-19 at 17:22 -0700, Luis R. Rodriguez wrote:
> On Tue, May 19, 2015 at 4:37 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Wed, 2015-05-20 at 00:19 +0200, Luis R. Rodriguez wrote:
> >> On Tue, May 19, 2015 at 05:48:37PM -0400, Mimi Zohar wrote:
> >> > On Tue, 2015-05-19 at 22:02 +0200, Luis R. Rodriguez wrote:

> > In this case, not only is there a
> > security hook, but the IMA hook exists as well.  To appraise firmware,
> > add a line to the IMA policy containing "appraise func=FIRMWARE_CHECK".
> > Similarly, to add a measurement to the measurement list, add a line to
> > the IMA policy containing "measure func=FIRMWAE_CHECK".
> 
> I have a series of reasons find IMA unsuitable for the current goals at hand:
> 
>   1) IMA is a pretty big kitchen sink, we want this to work well for
> even embedded systems, or architectures that do not have or require
> TPMs

There are different aspects to IMA.  One aspect is collecting file
measurements and extending the TPM with those measurements.  The other
aspect is appraising file integrity.  For that aspect, IMA-appraisal
does not use a TPM.

>   2) The appraisal is also done for to account for a specific state of
> affairs, you appraise to the user of the integrity of the system at a
> specific point in time,

True, IMA can be used to attest to the integrity of a system.

>  firmware signing can provide integrity /
> authorship vetting of files directly from the authors. 

It can also be used to appraise the integrity of a file, be it an
executable, a kernel module, configuration file or firmware in a
consistent manor, based on a file hash or signature.

> In the case of
> regulatory.bin that was the whole point of it, and firmware signing as
> is being provided is intended to generalize that but by sharing code
> in-kernel with module signing infrastructure

The underlying code used to verify the file signatures is the same.
The difference being where/how the file signatures are stored and which
keys to trust.   

> I am in hopes some others might be able to chime in more on point 2) here.
> 
> Don't get me wrong IMA is nice, but its a big chunky requirement to
> have, more than what module signing provides and what it requires
> today to replace subsystem file signing requirements.

> Now, LSM hooks -- that's more aligned with something we can start IMHO
> reasonably arguing we should shift module signing code to be punted
> into. But I've heard stories of LSM having issues with some virtual
> environments, and LSM stacking is also pretty new, and IMHO that'd be
> one way to compartmentalize all this module signing code. IMHO that
> *should happen* but can only be taken seriously once LSM stacking is
> merged in and baked. Its not, but I'm excited for it.

Have you even looked at IMA-appraisal?

> >> Now that we have LSM hooks stacked on the way perhaps this is more in line with
> >> what Andy has envisioned for alternatives for module signature verification.
> >> But then again since an LSM hook already exists for both modules and firmware
> >> perhaps this is sufficient for what Andy envisions? That is if folks do not want
> >> this signing thing just disable it and add use your preferred LSM module of choice?
> >>
> >> Now granted -- if we envision this module signing infrastructure as an LSM hook
> >> in and of itself perhaps we should LSM'ify it. Its not right now.
> >>
> >> > > I think we need one change here, we'd need to ensure that such key could only
> >> > > be used for vetting firmware files, not modules loaded.  The firmware_class
> >> > > could for instance still use all the keys in system_trusted_keyring, which
> >> > > would include the UEFI key db, but it does not seems reasonable to expect keys
> >> > > used for fw signing to also go into system_trusted_keyring to also be used for
> >> > > module signing.
> >> >
> >> > I agree totally!  For this reason, IMA defined a separate trusted
> >> > keyring to be used for verifying file signatures.
> >>
> >> OK I'll add that to my TODO list here.
> >
> > You'll probably want to create a new trusted firmware keyring.
> 
> Sure
> 
> >  By trusted, only signed keys by a key on the system_keyring can be added to
> > the.ima keyring.
> 
> If we go with IMA, I however do not think this would be appropriate
> and overkill at this point in time.

> > Using the "ca_keys" boot command line option a specific key on the system keyring can be specified.
> 
> Likewise.

Then on what basis will keys be added to the firmware keyring?

Mimi

Re: [RFD] linux-firmware key arrangement for firmware signing

[Andy Lutomirski]

On Tue, May 19, 2015 at 6:06 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Tue, 2015-05-19 at 17:22 -0700, Luis R. Rodriguez wrote:
>> On Tue, May 19, 2015 at 4:37 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
>> > On Wed, 2015-05-20 at 00:19 +0200, Luis R. Rodriguez wrote:
>> >> On Tue, May 19, 2015 at 05:48:37PM -0400, Mimi Zohar wrote:
>> >> > On Tue, 2015-05-19 at 22:02 +0200, Luis R. Rodriguez wrote:
>
>> > In this case, not only is there a
>> > security hook, but the IMA hook exists as well.  To appraise firmware,
>> > add a line to the IMA policy containing "appraise func=FIRMWARE_CHECK".
>> > Similarly, to add a measurement to the measurement list, add a line to
>> > the IMA policy containing "measure func=FIRMWAE_CHECK".
>>
>> I have a series of reasons find IMA unsuitable for the current goals at hand:
>>
>>   1) IMA is a pretty big kitchen sink, we want this to work well for
>> even embedded systems, or architectures that do not have or require
>> TPMs
>
> There are different aspects to IMA.  One aspect is collecting file
> measurements and extending the TPM with those measurements.  The other
> aspect is appraising file integrity.  For that aspect, IMA-appraisal
> does not use a TPM.
>
>>   2) The appraisal is also done for to account for a specific state of
>> affairs, you appraise to the user of the integrity of the system at a
>> specific point in time,
>
> True, IMA can be used to attest to the integrity of a system.
>
>>  firmware signing can provide integrity /
>> authorship vetting of files directly from the authors.
>
> It can also be used to appraise the integrity of a file, be it an
> executable, a kernel module, configuration file or firmware in a
> consistent manor, based on a file hash or signature.
>
>> In the case of
>> regulatory.bin that was the whole point of it, and firmware signing as
>> is being provided is intended to generalize that but by sharing code
>> in-kernel with module signing infrastructure
>
> The underlying code used to verify the file signatures is the same.
> The difference being where/how the file signatures are stored and which
> keys to trust.
>
>> I am in hopes some others might be able to chime in more on point 2) here.
>>
>> Don't get me wrong IMA is nice, but its a big chunky requirement to
>> have, more than what module signing provides and what it requires
>> today to replace subsystem file signing requirements.
>
>> Now, LSM hooks -- that's more aligned with something we can start IMHO
>> reasonably arguing we should shift module signing code to be punted
>> into. But I've heard stories of LSM having issues with some virtual
>> environments, and LSM stacking is also pretty new, and IMHO that'd be
>> one way to compartmentalize all this module signing code. IMHO that
>> *should happen* but can only be taken seriously once LSM stacking is
>> merged in and baked. Its not, but I'm excited for it.
>
> Have you even looked at IMA-appraisal?

I just looked extremely briefly.  It seems to be much simpler than the
PKCS#7 thing.  OTOH, it seems to hardcode some rather scary
assumptions that it's using RSA in digsig_asymmetric.c, specifically:

        pks.rsa.s = mpi_read_raw_data(hdr->sig, siglen);

This bit in ima_appraise_measurement ignores trailing junk.  Why?

                if (xattr_len - sizeof(xattr_value->type) - hash_start >=
                                iint->ima_hash->length)
                        /* xattr length may be longer. md5 hash in previous
                           version occupied 20 bytes in xattr, instead of 16
                         */
                        rc = memcmp(&xattr_value->digest[hash_start],
                                    iint->ima_hash->digest,
                                    iint->ima_hash->length);

I got confused around here:

                        /* Replace RSA with HMAC if not mounted readonly and
                         * not immutable
                         */
                        if (!IS_RDONLY(dentry->d_inode) &&
                            !IS_IMMUTABLE(dentry->d_inode))
                                evm_update_evmxattr(dentry, xattr_name,
                                                    xattr_value,
                                                    xattr_value_len);

Huh?

Anyway, AFAICT IMA is about tracking the integrity of an FS that's
being actively modified, not about distributing signed things.  Also,
I couldn't spot what part of IMA detects an attacker replacing one
signed file with a different one from the same filesystem but a
different name.

--Andy

Re: [RFD] linux-firmware key arrangement for firmware signing

[Mimi Zohar]

On Tue, 2015-05-19 at 18:29 -0700, Andy Lutomirski wrote:
> On Tue, May 19, 2015 at 6:06 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Tue, 2015-05-19 at 17:22 -0700, Luis R. Rodriguez wrote:
> >> On Tue, May 19, 2015 at 4:37 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> >> > On Wed, 2015-05-20 at 00:19 +0200, Luis R. Rodriguez wrote:
> >> >> On Tue, May 19, 2015 at 05:48:37PM -0400, Mimi Zohar wrote:
> >> >> > On Tue, 2015-05-19 at 22:02 +0200, Luis R. Rodriguez wrote:
> >
> >> > In this case, not only is there a
> >> > security hook, but the IMA hook exists as well.  To appraise firmware,
> >> > add a line to the IMA policy containing "appraise func=FIRMWARE_CHECK".
> >> > Similarly, to add a measurement to the measurement list, add a line to
> >> > the IMA policy containing "measure func=FIRMWAE_CHECK".
> >>
> >> I have a series of reasons find IMA unsuitable for the current goals at hand:
> >>
> >>   1) IMA is a pretty big kitchen sink, we want this to work well for
> >> even embedded systems, or architectures that do not have or require
> >> TPMs
> >
> > There are different aspects to IMA.  One aspect is collecting file
> > measurements and extending the TPM with those measurements.  The other
> > aspect is appraising file integrity.  For that aspect, IMA-appraisal
> > does not use a TPM.
> >
> >>   2) The appraisal is also done for to account for a specific state of
> >> affairs, you appraise to the user of the integrity of the system at a
> >> specific point in time,
> >
> > True, IMA can be used to attest to the integrity of a system.
> >
> >>  firmware signing can provide integrity /
> >> authorship vetting of files directly from the authors.
> >
> > It can also be used to appraise the integrity of a file, be it an
> > executable, a kernel module, configuration file or firmware in a
> > consistent manor, based on a file hash or signature.
> >
> >> In the case of
> >> regulatory.bin that was the whole point of it, and firmware signing as
> >> is being provided is intended to generalize that but by sharing code
> >> in-kernel with module signing infrastructure
> >
> > The underlying code used to verify the file signatures is the same.
> > The difference being where/how the file signatures are stored and which
> > keys to trust.
> >
> >> I am in hopes some others might be able to chime in more on point 2) here.
> >>
> >> Don't get me wrong IMA is nice, but its a big chunky requirement to
> >> have, more than what module signing provides and what it requires
> >> today to replace subsystem file signing requirements.
> >
> >> Now, LSM hooks -- that's more aligned with something we can start IMHO
> >> reasonably arguing we should shift module signing code to be punted
> >> into. But I've heard stories of LSM having issues with some virtual
> >> environments, and LSM stacking is also pretty new, and IMHO that'd be
> >> one way to compartmentalize all this module signing code. IMHO that
> >> *should happen* but can only be taken seriously once LSM stacking is
> >> merged in and baked. Its not, but I'm excited for it.
> >
> > Have you even looked at IMA-appraisal?
> 
> I just looked extremely briefly.  It seems to be much simpler than the
> PKCS#7 thing.  OTOH, it seems to hardcode some rather scary
> assumptions that it's using RSA in digsig_asymmetric.c, specifically:
> 
>         pks.rsa.s = mpi_read_raw_data(hdr->sig, siglen);
> This bit in ima_appraise_measurement ignores trailing junk.  Why?

The same field is used to store either an MD5 or a SHA1 hash.  The hash
length is dependent on the hash algorithm

>                 if (xattr_len - sizeof(xattr_value->type) - hash_start >=
>                                 iint->ima_hash->length)
>                         /* xattr length may be longer. md5 hash in previous
>                            version occupied 20 bytes in xattr, instead of 16
>                          */
>                         rc = memcmp(&xattr_value->digest[hash_start],
>                                     iint->ima_hash->digest,
>                                     iint->ima_hash->length);
> 
> I got confused around here:
> 
>                         /* Replace RSA with HMAC if not mounted readonly and
>                          * not immutable
>                          */
>                         if (!IS_RDONLY(dentry->d_inode) &&
>                             !IS_IMMUTABLE(dentry->d_inode))
>                                 evm_update_evmxattr(dentry, xattr_name,
>                                                     xattr_value,
>                                                     xattr_value_len);
> 
> Huh?

EVM signatures are replaced with a keyed HMAC.     

> 
> Anyway, AFAICT IMA is about tracking the integrity of an FS that's
> being actively modified, not about distributing signed things. 

Files that are signed are considered immutable and do not change
(ima_appraise_measurement: case EVM_IMA_XATTR_DIGSIG).

Fin posted RPM patches to store file signatures in the RPM header.
Similarly, I posted patches to include file signatures in deb packages.
(We still need to upstream these patches.)

>  Also,
> I couldn't spot what part of IMA detects an attacker replacing one
> signed file with a different one from the same filesystem but a
> different name.

Perhaps you're referring to EVM?

Mimi

Re: [RFD] linux-firmware key arrangement for firmware signing

[Andy Lutomirski]

On Tue, May 19, 2015 at 7:05 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Tue, 2015-05-19 at 18:29 -0700, Andy Lutomirski wrote:
>> On Tue, May 19, 2015 at 6:06 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
>> > On Tue, 2015-05-19 at 17:22 -0700, Luis R. Rodriguez wrote:
>> >> On Tue, May 19, 2015 at 4:37 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
>> >> > On Wed, 2015-05-20 at 00:19 +0200, Luis R. Rodriguez wrote:
>> >> >> On Tue, May 19, 2015 at 05:48:37PM -0400, Mimi Zohar wrote:
>> >> >> > On Tue, 2015-05-19 at 22:02 +0200, Luis R. Rodriguez wrote:
>> >
>> >> > In this case, not only is there a
>> >> > security hook, but the IMA hook exists as well.  To appraise firmware,
>> >> > add a line to the IMA policy containing "appraise func=FIRMWARE_CHECK".
>> >> > Similarly, to add a measurement to the measurement list, add a line to
>> >> > the IMA policy containing "measure func=FIRMWAE_CHECK".
>> >>
>> >> I have a series of reasons find IMA unsuitable for the current goals at hand:
>> >>
>> >>   1) IMA is a pretty big kitchen sink, we want this to work well for
>> >> even embedded systems, or architectures that do not have or require
>> >> TPMs
>> >
>> > There are different aspects to IMA.  One aspect is collecting file
>> > measurements and extending the TPM with those measurements.  The other
>> > aspect is appraising file integrity.  For that aspect, IMA-appraisal
>> > does not use a TPM.
>> >
>> >>   2) The appraisal is also done for to account for a specific state of
>> >> affairs, you appraise to the user of the integrity of the system at a
>> >> specific point in time,
>> >
>> > True, IMA can be used to attest to the integrity of a system.
>> >
>> >>  firmware signing can provide integrity /
>> >> authorship vetting of files directly from the authors.
>> >
>> > It can also be used to appraise the integrity of a file, be it an
>> > executable, a kernel module, configuration file or firmware in a
>> > consistent manor, based on a file hash or signature.
>> >
>> >> In the case of
>> >> regulatory.bin that was the whole point of it, and firmware signing as
>> >> is being provided is intended to generalize that but by sharing code
>> >> in-kernel with module signing infrastructure
>> >
>> > The underlying code used to verify the file signatures is the same.
>> > The difference being where/how the file signatures are stored and which
>> > keys to trust.
>> >
>> >> I am in hopes some others might be able to chime in more on point 2) here.
>> >>
>> >> Don't get me wrong IMA is nice, but its a big chunky requirement to
>> >> have, more than what module signing provides and what it requires
>> >> today to replace subsystem file signing requirements.
>> >
>> >> Now, LSM hooks -- that's more aligned with something we can start IMHO
>> >> reasonably arguing we should shift module signing code to be punted
>> >> into. But I've heard stories of LSM having issues with some virtual
>> >> environments, and LSM stacking is also pretty new, and IMHO that'd be
>> >> one way to compartmentalize all this module signing code. IMHO that
>> >> *should happen* but can only be taken seriously once LSM stacking is
>> >> merged in and baked. Its not, but I'm excited for it.
>> >
>> > Have you even looked at IMA-appraisal?
>>
>> I just looked extremely briefly.  It seems to be much simpler than the
>> PKCS#7 thing.  OTOH, it seems to hardcode some rather scary
>> assumptions that it's using RSA in digsig_asymmetric.c, specifically:
>>
>>         pks.rsa.s = mpi_read_raw_data(hdr->sig, siglen);
>> This bit in ima_appraise_measurement ignores trailing junk.  Why?
>
> The same field is used to store either an MD5 or a SHA1 hash.  The hash
> length is dependent on the hash algorithm

I still don't understand why there would be trailing junk.  Surely the
stored hash length should match the computed hash length, no?

>
>>                 if (xattr_len - sizeof(xattr_value->type) - hash_start >=
>>                                 iint->ima_hash->length)
>>                         /* xattr length may be longer. md5 hash in previous
>>                            version occupied 20 bytes in xattr, instead of 16
>>                          */
>>                         rc = memcmp(&xattr_value->digest[hash_start],
>>                                     iint->ima_hash->digest,
>>                                     iint->ima_hash->length);
>>
>> I got confused around here:
>>
>>                         /* Replace RSA with HMAC if not mounted readonly and
>>                          * not immutable
>>                          */
>>                         if (!IS_RDONLY(dentry->d_inode) &&
>>                             !IS_IMMUTABLE(dentry->d_inode))
>>                                 evm_update_evmxattr(dentry, xattr_name,
>>                                                     xattr_value,
>>                                                     xattr_value_len);
>>
>> Huh?
>
> EVM signatures are replaced with a keyed HMAC.
>
>>
>> Anyway, AFAICT IMA is about tracking the integrity of an FS that's
>> being actively modified, not about distributing signed things.
>
> Files that are signed are considered immutable and do not change
> (ima_appraise_measurement: case EVM_IMA_XATTR_DIGSIG).
>
> Fin posted RPM patches to store file signatures in the RPM header.
> Similarly, I posted patches to include file signatures in deb packages.
> (We still need to upstream these patches.)

I'm at a loss as to how this would work or how it would make sense for
what Luis is trying to do.

>
>>  Also,
>> I couldn't spot what part of IMA detects an attacker replacing one
>> signed file with a different one from the same filesystem but a
>> different name.
>
> Perhaps you're referring to EVM?

I don't know.  I also couldn't figure out what IMA was and what EVM was.

--Andy

Re: [RFD] linux-firmware key arrangement for firmware signing

[Petko Manolov]

On 15-05-19 19:10:07, Andy Lutomirski wrote:
> On Tue, May 19, 2015 at 7:05 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> >
> > Perhaps you're referring to EVM?
> 
> I don't know.  I also couldn't figure out what IMA was and what EVM was.

Try reading this:

http://sourceforge.net/p/linux-ima/wiki/Home/

A little outdated with some bits missing, but definitely worth reading.  It will 
also help lower the noise in LSM mailing list. :)


		Petko

Re: [RFD] linux-firmware key arrangement for firmware signing

[Petko Manolov]

On 15-05-19 17:22:59, Luis R. Rodriguez wrote:
>
> I have a series of reasons find IMA unsuitable for the current goals at hand:
> 
>   1) IMA is a pretty big kitchen sink, we want this to work well for
> even embedded systems, or architectures that do not have or require
> TPMs

No, it isn't.  I've profiled it and performance hit is negligible.  All hash 
algorithms used have been optimized for most cpu architectures.

>   2) The appraisal is also done for to account for a specific state of
> affairs, you appraise to the user of the integrity of the system at a
> specific point in time, firmware signing can provide integrity /
> authorship vetting of files directly from the authors. In the case of
> regulatory.bin that was the whole point of it, and firmware signing as
> is being provided is intended to generalize that but by sharing code
> in-kernel with module signing infrastructure

This is weird English to me, but since i am no native speaker either i'll blame 
myself. :)  Could you please rephrase?

> If we go with IMA, I however do not think this would be appropriate and 
> overkill at this point in time.

Depends on what your needs are.  If you need authenticity then IMA-appraise is 
definitely your way to go.  For anything less secure you may go with LSM of 
choice to apply whatever policy you may have in mind.

Again, security and convenience do not play well together.


		Petko

Re: [RFD] linux-firmware key arrangement for firmware signing

[Seth Forshee]

On Tue, May 19, 2015 at 10:02:32PM +0200, Luis R. Rodriguez wrote:
> This begs the question on how we'd manage keys for firmware signing on
> linux-firmare. Since the keys are x509 keys we need a CA. Based on some initial
> discussions it would seem we'd need the Linux Foundation to create a key, this
> would be embedded in the kernel and that key would be used to sign Kyle's key.
> Kyle would in turn use his key for signing linux-firmware files. David, Kyle,
> did I summarize this correctly ?

I raised the question of key revocation when we discussed this on irc,
but it wasn't answered to my satisfaction. If a key signed by the
kernel-embedded key is compromised, how can that key be revoked so that
it is no longer trusted?

Someone mentioned UEFI blacklists, which I don't know much about, but
not all systems have UEFI. The only reliable option that comes to mind
for me is an in-kernel blacklist of keys which should no longer be
trusted.

Seth

Re: [RFD] linux-firmware key arrangement for firmware signing

[David Howells]

Seth Forshee <seth.forshee@canonical.com> wrote:

> > This begs the question on how we'd manage keys for firmware signing on
> > linux-firmare. Since the keys are x509 keys we need a CA. Based on some
> > initial discussions it would seem we'd need the Linux Foundation to create
> > a key, this would be embedded in the kernel and that key would be used to
> > sign Kyle's key.  Kyle would in turn use his key for signing
> > linux-firmware files. David, Kyle, did I summarize this correctly ?
> 
> I raised the question of key revocation when we discussed this on irc,
> but it wasn't answered to my satisfaction. If a key signed by the
> kernel-embedded key is compromised, how can that key be revoked so that
> it is no longer trusted?
> 
> Someone mentioned UEFI blacklists, which I don't know much about, but
> not all systems have UEFI. The only reliable option that comes to mind
> for me is an in-kernel blacklist of keys which should no longer be
> trusted.

Key revocation is generally an unpleasant problem.  How do you inform a system
that a key of any sort is revoked?  With PGP, for instance, you might be able
to connect to the net and consult a server.

UEFI has a blacklist that can theoretically be used to prevent both usage of a
key and usage of a particular object.  As I understand it, the blacklist in
UEFI is just a table of SHA256 hashes.

Relying on UEFI presents three problems, though: (1) the system admin has to
manually, as far as I'm aware, inform the BIOS; (2) the UEFI storage is
limited; and (3) not all systems have UEFI.

What you do on a non-UEFI system, I'm not sure.  If the kernel isn't verified
by the loader or the system firmware then you don't have a 'fully' secure
system anyway and the blacklist may be of questionable value.

David

Re: [RFD] linux-firmware key arrangement for firmware signing

[Seth Forshee]

On Wed, May 20, 2015 at 04:08:58PM +0100, David Howells wrote:
> Seth Forshee <seth.forshee@canonical.com> wrote:
> 
> > > This begs the question on how we'd manage keys for firmware signing on
> > > linux-firmare. Since the keys are x509 keys we need a CA. Based on some
> > > initial discussions it would seem we'd need the Linux Foundation to create
> > > a key, this would be embedded in the kernel and that key would be used to
> > > sign Kyle's key.  Kyle would in turn use his key for signing
> > > linux-firmware files. David, Kyle, did I summarize this correctly ?
> > 
> > I raised the question of key revocation when we discussed this on irc,
> > but it wasn't answered to my satisfaction. If a key signed by the
> > kernel-embedded key is compromised, how can that key be revoked so that
> > it is no longer trusted?
> > 
> > Someone mentioned UEFI blacklists, which I don't know much about, but
> > not all systems have UEFI. The only reliable option that comes to mind
> > for me is an in-kernel blacklist of keys which should no longer be
> > trusted.
> 
> Key revocation is generally an unpleasant problem.  How do you inform a system
> that a key of any sort is revoked?  With PGP, for instance, you might be able
> to connect to the net and consult a server.

Distros could distribute updates to the blacklist via their usual update
mechanisms. That could be a new kernel with an updated blacklist (after
all we should expect blacklist updates to be very infrequent).

I suppose a database in the initrd which was loaded prior to loading any
firmware could work too, then perhaps new blacklists could be loaded
into a running kernel without a reboot as well. But that database should
probably be signed too, which creates a chicken-and-egg sort of problem.

> UEFI has a blacklist that can theoretically be used to prevent both usage of a
> key and usage of a particular object.  As I understand it, the blacklist in
> UEFI is just a table of SHA256 hashes.
> 
> Relying on UEFI presents three problems, though: (1) the system admin has to
> manually, as far as I'm aware, inform the BIOS; (2) the UEFI storage is
> limited; and (3) not all systems have UEFI.

Yeah, that doesn't really sound like a good solution. Not all users are
sys admins.

> What you do on a non-UEFI system, I'm not sure.  If the kernel isn't verified
> by the loader or the system firmware then you don't have a 'fully' secure
> system anyway and the blacklist may be of questionable value.

I think there's still value - compromised firmware could easily be a
vector to compromise the kernel. Just because I can't verify my system
security doesn't mean that I don't want measures in place to keep it
from being compromised.

Seth

Re: [RFD] linux-firmware key arrangement for firmware signing

[David Howells]

Seth Forshee <seth.forshee@canonical.com> wrote:

> > Relying on UEFI presents three problems, though: (1) the system admin has to
> > manually, as far as I'm aware, inform the BIOS; (2) the UEFI storage is
> > limited; and (3) not all systems have UEFI.
> 
> Yeah, that doesn't really sound like a good solution. Not all users are
> sys admins.

Yeah.  We don't really want to recommend they go meddling lest they brick
their machine by triggering a bug in their BIOS.  Not that there *are* any
buggy BIOSes of course;-)

David

Re: [RFD] linux-firmware key arrangement for firmware signing

[One Thousand Gnomes]

On Wed, 20 May 2015 09:04:26 -0500
Seth Forshee <seth.forshee@canonical.com> wrote:

> On Tue, May 19, 2015 at 10:02:32PM +0200, Luis R. Rodriguez wrote:
> > This begs the question on how we'd manage keys for firmware signing on
> > linux-firmare. Since the keys are x509 keys we need a CA. Based on some initial
> > discussions it would seem we'd need the Linux Foundation to create a key, this
> > would be embedded in the kernel and that key would be used to sign Kyle's key.
> > Kyle would in turn use his key for signing linux-firmware files. David, Kyle,
> > did I summarize this correctly ?
> 
> I raised the question of key revocation when we discussed this on irc,
> but it wasn't answered to my satisfaction. If a key signed by the
> kernel-embedded key is compromised, how can that key be revoked so that
> it is no longer trusted?
> 
> Someone mentioned UEFI blacklists, which I don't know much about, but
> not all systems have UEFI. The only reliable option that comes to mind
> for me is an in-kernel blacklist of keys which should no longer be
> trusted.

More to the point why do you want to sign firmware files ? Leaving aside
the fact that someone will produce a device with GPLv3 firmware just to
p*ss you off there's the rather more relevant fact that firmware for
devices on a so called "trusted" platform already have signed firmware.

For external devices I don't normally have access to read system memory
anyway, and signing firmware would achieve nothing unless you start doing
crazy DRM style key exchanges to prove the endpoint is trusted. Any NSA
trojan wifi stick is simply going to nod as the correct firmware is
uploaded, and then ignore it. And if I'm just out to be a pain I can
already just plug in a fake device claiming to be a usb disk with 256
bytes per sector (boom... exit machine stage right), or for that matter
wire a USB stick with 5v connected to the mains at the nearest wall
socket.

So I don't think I understand the threat model your signing hopes to fix ?

Alan

Re: [RFD] linux-firmware key arrangement for firmware signing

[Petko Manolov]

On 15-05-20 17:24:46, One Thousand Gnomes wrote:
> 
> More to the point why do you want to sign firmware files ? Leaving aside the 
> fact that someone will produce a device with GPLv3 firmware just to p*ss you 
> off there's the rather more relevant fact that firmware for devices on a so 
> called "trusted" platform already have signed firmware.

For "trusted" systems one would like to make sure everything that goes in has 
known provenance.  Maybe this was the idea?

> For external devices I don't normally have access to read system memory 
> anyway, and signing firmware would achieve nothing unless you start doing 
> crazy DRM style key exchanges to prove the endpoint is trusted. Any NSA trojan 
> wifi stick is simply going to nod as the correct firmware is uploaded, and 
> then ignore it. And if I'm just out to be a pain I can already just plug in a 
> fake device claiming to be a usb disk with 256 bytes per sector (boom... exit 
> machine stage right), or for that matter wire a USB stick with 5v connected to 
> the mains at the nearest wall socket.

Yep, gaining physical access to the system is a game over.  It is arguable how 
"trusted" a networked machine could be and i guess the answer is "not much"...


		Petko

Re: [RFD] linux-firmware key arrangement for firmware signing

[Greg Kroah-Hartman]

On Wed, May 20, 2015 at 07:46:13PM +0300, Petko Manolov wrote:
> On 15-05-20 17:24:46, One Thousand Gnomes wrote:
> > 
> > More to the point why do you want to sign firmware files ? Leaving aside the 
> > fact that someone will produce a device with GPLv3 firmware just to p*ss you 
> > off there's the rather more relevant fact that firmware for devices on a so 
> > called "trusted" platform already have signed firmware.
> 
> For "trusted" systems one would like to make sure everything that goes in has 
> known provenance.  Maybe this was the idea?

If so, then just do what people do today, verify their known valid disk
image before mounting it and then they know they can trust the data on
it to be use for whatever (including firmware.)  No kernel changes
needed, distro support is already there for this.

I too don't understand this need to sign something that you don't really
know what it is from some other company, just to send it to a separate
device that is going to do whatever it wants with it if it is signed or
not.

thanks,

greg k-h

Re: [RFD] linux-firmware key arrangement for firmware signing

[Petko Manolov]

On 15-05-20 21:41:04, Greg Kroah-Hartman wrote:
> On Wed, May 20, 2015 at 07:46:13PM +0300, Petko Manolov wrote:
> > On 15-05-20 17:24:46, One Thousand Gnomes wrote:
> > > 
> > > More to the point why do you want to sign firmware files ? Leaving aside the 
> > > fact that someone will produce a device with GPLv3 firmware just to p*ss you 
> > > off there's the rather more relevant fact that firmware for devices on a so 
> > > called "trusted" platform already have signed firmware.
> > 
> > For "trusted" systems one would like to make sure everything that goes in has 
> > known provenance.  Maybe this was the idea?
> 
> If so, then just do what people do today, verify their known valid disk image 
> before mounting it and then they know they can trust the data on it to be use 
> for whatever (including firmware.)  No kernel changes needed, distro support 
> is already there for this.

I do agree, the infrastructure is already in place.  The project i am working on 
has very strict security requirements, quite unlike regular Linux box.  I was 
pleasantly surprised that it didn't take much kernel hacking to get to the point 
where stuff is working to our liking.

> I too don't understand this need to sign something that you don't really know 
> what it is from some other company, just to send it to a separate device that 
> is going to do whatever it wants with it if it is signed or not.

This is not the point.  What you need to know is _where_ the firmware came from, 
not _what_ it does once it reach your system.  If you don't care about such 
things, just ignore the signature. :)


		Petko

Re: [RFD] linux-firmware key arrangement for firmware signing

[Greg Kroah-Hartman]

On Thu, May 21, 2015 at 08:41:02AM +0300, Petko Manolov wrote:
> > I too don't understand this need to sign something that you don't really know 
> > what it is from some other company, just to send it to a separate device that 
> > is going to do whatever it wants with it if it is signed or not.
> 
> This is not the point.  What you need to know is _where_ the firmware came from, 
> not _what_ it does once it reach your system.  If you don't care about such 
> things, just ignore the signature. :)

Ok, but how do we know "where"?  Who is going to start signing and
attesting to the validity of all of the firmware images in the
linux-firmware tree suddenly?  Why is it the kernel's job to attest this
"where"?  Shouldn't your distro/manufacturer be doing that as part of
their "put this file on this disk" responsibilities (i.e. the package
manager?)

What is verifying a firmware image signature in the kernel attesting
that isn't already known in userspace?

thanks,

greg k-h

Re: [RFD] linux-firmware key arrangement for firmware signing

[Mimi Zohar]

On Wed, 2015-05-20 at 23:14 -0700, Greg Kroah-Hartman wrote:
> On Thu, May 21, 2015 at 08:41:02AM +0300, Petko Manolov wrote:
> > > I too don't understand this need to sign something that you don't really know 
> > > what it is from some other company, just to send it to a separate device that 
> > > is going to do whatever it wants with it if it is signed or not.
> > 
> > This is not the point.  What you need to know is _where_ the firmware came from, 
> > not _what_ it does once it reach your system.  If you don't care about such 
> > things, just ignore the signature. :)
> 
> Ok, but how do we know "where"?  Who is going to start signing and
> attesting to the validity of all of the firmware images in the
> linux-firmware tree suddenly?  Why is it the kernel's job to attest this
> "where"?  Shouldn't your distro/manufacturer be doing that as part of
> their "put this file on this disk" responsibilities (i.e. the package
> manager?)

Signatures don't provide any guarantees as to code quality or
correctness.   They do provide file integrity and provenance.  In
addition to the license and a Signed-off-by line, having the firmware
provider include a signature of the firmware would be nice.

> What is verifying a firmware image signature in the kernel attesting
> that isn't already known in userspace?

Appraising and enforcing firmware integrity before use.

Mimi

Re: [RFD] linux-firmware key arrangement for firmware signing

[Greg Kroah-Hartman]

On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote:
> On Wed, 2015-05-20 at 23:14 -0700, Greg Kroah-Hartman wrote:
> > On Thu, May 21, 2015 at 08:41:02AM +0300, Petko Manolov wrote:
> > > > I too don't understand this need to sign something that you don't really know 
> > > > what it is from some other company, just to send it to a separate device that 
> > > > is going to do whatever it wants with it if it is signed or not.
> > > 
> > > This is not the point.  What you need to know is _where_ the firmware came from, 
> > > not _what_ it does once it reach your system.  If you don't care about such 
> > > things, just ignore the signature. :)
> > 
> > Ok, but how do we know "where"?  Who is going to start signing and
> > attesting to the validity of all of the firmware images in the
> > linux-firmware tree suddenly?  Why is it the kernel's job to attest this
> > "where"?  Shouldn't your distro/manufacturer be doing that as part of
> > their "put this file on this disk" responsibilities (i.e. the package
> > manager?)
> 
> Signatures don't provide any guarantees as to code quality or
> correctness.   They do provide file integrity and provenance.  In
> addition to the license and a Signed-off-by line, having the firmware
> provider include a signature of the firmware would be nice.

That would be "nice", but that's not going to be happening here, from
what I can tell.  The firmware provider should be putting the signature
inside the firmware image itself, and verifying it on the device, in
order to properly "know" that it should be running that firmware.  The
kernel shouldn't be involved here at all, as Alan pointed out.

> > What is verifying a firmware image signature in the kernel attesting
> > that isn't already known in userspace?
> 
> Appraising and enforcing firmware integrity before use.

That should be done on the device itself, not in the kernel.

thanks,

greg k-h

Re: [RFD] linux-firmware key arrangement for firmware signing

[Petko Manolov]

On 15-05-21 08:45:08, Greg Kroah-Hartman wrote:
> On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote:
> > 
> > Signatures don't provide any guarantees as to code quality or
> > correctness.   They do provide file integrity and provenance.  In
> > addition to the license and a Signed-off-by line, having the firmware
> > provider include a signature of the firmware would be nice.
> 
> That would be "nice", but that's not going to be happening here, from what I 
> can tell.  The firmware provider should be putting the signature inside the 
> firmware image itself, and verifying it on the device, in order to properly 
> "know" that it should be running that firmware.  The kernel shouldn't be 
> involved here at all, as Alan pointed out.

It is device's job to verify firmware's correctness.  It is user's job to verify 
vendor's identity.  Two different things, not related to each other.

I think Alan meant something else.  What i read is that if somebody have 
physical access to the device they may harm the device much easier and would 
not bother to tamper with firmware.

> > > What is verifying a firmware image signature in the kernel attesting
> > > that isn't already known in userspace?
> > 
> > Appraising and enforcing firmware integrity before use.
> 
> That should be done on the device itself, not in the kernel.

Oh, well...

Re: [RFD] linux-firmware key arrangement for firmware signing

[Greg Kroah-Hartman]

On Thu, May 21, 2015 at 06:53:19PM +0300, Petko Manolov wrote:
> On 15-05-21 08:45:08, Greg Kroah-Hartman wrote:
> > On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote:
> > > 
> > > Signatures don't provide any guarantees as to code quality or
> > > correctness.   They do provide file integrity and provenance.  In
> > > addition to the license and a Signed-off-by line, having the firmware
> > > provider include a signature of the firmware would be nice.
> > 
> > That would be "nice", but that's not going to be happening here, from what I 
> > can tell.  The firmware provider should be putting the signature inside the 
> > firmware image itself, and verifying it on the device, in order to properly 
> > "know" that it should be running that firmware.  The kernel shouldn't be 
> > involved here at all, as Alan pointed out.
> 
> It is device's job to verify firmware's correctness.  It is user's job to verify 
> vendor's identity.  Two different things, not related to each other.

The device can also verify "is this firmware from a trusted source", and
it should if it is a "good" device.  "correctness" can just be a simple
checksum, and I think most of the firmware blobs already have that in
them :)

Are these patches "verifying the vendor"?  Right now it just looks like
they are "verifying the packager" as none of the hundreds of firmware
images we have actually have stand-alone signatures.

Do we have firmware images that are going to be signed by the vendor?
If so, are they also not signed in the firmware itself?  Why are we
forcing the kernel to do this verification that the device should be
doing instead?

thanks,

greg k-h

Re: [RFD] linux-firmware key arrangement for firmware signing

[One Thousand Gnomes]

On Thu, 21 May 2015 18:53:19 +0300
Petko Manolov <petkan@mip-labs.com> wrote:

> On 15-05-21 08:45:08, Greg Kroah-Hartman wrote:
> > On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote:
> > > 
> > > Signatures don't provide any guarantees as to code quality or
> > > correctness.   They do provide file integrity and provenance.  In
> > > addition to the license and a Signed-off-by line, having the firmware
> > > provider include a signature of the firmware would be nice.
> > 
> > That would be "nice", but that's not going to be happening here, from what I 
> > can tell.  The firmware provider should be putting the signature inside the 
> > firmware image itself, and verifying it on the device, in order to properly 
> > "know" that it should be running that firmware.  The kernel shouldn't be 
> > involved here at all, as Alan pointed out.
> 
> It is device's job to verify firmware's correctness.  It is user's job to verify 
> vendor's identity.  Two different things, not related to each other.

The device verifies the firmwares identity. The firmware's correctness is
unknownable if the mathematicians are correct.

The device will accept firmware signed in some manner with some key that
is probably part of a root of trust embedded deeply im the hardware
itself. If it's vendor X hardware then firmware not signed with the key
for that hardware won't work, and vendor X has the key locked away.

It's also worth remembering most of the dumb non signature checking
devices are things like USB. They don't have access to the internals of
the system so their attack options are more limited.

On Thu, 21 May 2015 16:03:02 +0000
"Woodhouse, David" <david.woodhouse@intel.com> wrote:

> In the case where kernel and modules are signed, it *is* useful for a
> kernel device driver also to be able to validate that what it's about
> to load into a device is authentic.

You also need to know its "authentic" for that specific device. Otherwise
you may be able to exploit something by loading an authentic firmware for
another piece of hardware.

Ie you need to sign something more than the firmware, such as (firmware,
modinfo), so it's signed for "firmware X on PCI:8086,1114 or "firmware Y
on ACPI:0A1D"

I want to understand the model, who signs what, and what security is
allegedly provided over the existing. If there are users sufficiently
paranoid to believe that signing firmware saves them, then fine. For
most hardware it can cut out some attackers, although anyone with
sufficient money or a TLA can no doubt just tap someone on the shoulder
and say you are signing this for us.

IMHO we want the supplier of a given firmware providing signatures on
the firmware git tree if this is done. A generic linux-firmware owned key
would be both a horrendously inviting attack target, and a single point of
failure.

Git can already do all the needed commit signing bits unless I'm missing
something here ?

Alan

Re: [RFD] linux-firmware key arrangement for firmware signing

[Petko Manolov]

On 15-05-26 18:08:13, One Thousand Gnomes wrote:
> On Thu, 21 May 2015 18:53:19 +0300
> Petko Manolov <petkan@mip-labs.com> wrote:
> 
> > It is device's job to verify firmware's correctness.  It is user's job to 
> > verify vendor's identity.  Two different things, not related to each other.
> 
> The device verifies the firmwares identity. The firmware's correctness is 
> unknownable if the mathematicians are correct.

Or so the story goes... :)

Anyway, bad choice of words.  I meant to say its device's responsibility to 
verify binary blob's integrity, be it firmware or something else.

> The device will accept firmware signed in some manner with some key that is 
> probably part of a root of trust embedded deeply im the hardware itself. If 
> it's vendor X hardware then firmware not signed with the key for that hardware 
> won't work, and vendor X has the key locked away.

Ideally, this would be the case.  However, as far as i know there is very few 
devices out there that will do what you describe.  First, it is complex.  
Second, and more important, it is expensive.  Third, if the root of trust is 
compromised the device is done for.  Or rather its user.

Considering the above i guess this isn't going to happen anytime soon, except 
for highly specialized devices.  Of course i may not be correct.  In 
mathematical sense as well. :)

> It's also worth remembering most of the dumb non signature checking devices 
> are things like USB. They don't have access to the internals of the system so 
> their attack options are more limited.

Most devices just lack the infrastructure.  Especially those that are used in 
the embedded world.  Very few of them are designed to withstand relatively 
moderate attempt on their security.  Speaking about hardware.  Come the software, 
things are quickly getting messier.


> On Thu, 21 May 2015 16:03:02 +0000
> "Woodhouse, David" <david.woodhouse@intel.com> wrote:
> 
> > In the case where kernel and modules are signed, it *is* useful for a kernel 
> > device driver also to be able to validate that what it's about to load into 
> > a device is authentic.
> 
> You also need to know its "authentic" for that specific device. Otherwise you 
> may be able to exploit something by loading an authentic firmware for another 
> piece of hardware.

Well, yes this may easily happen.  Integrity checks aren't going to help here.

> Ie you need to sign something more than the firmware, such as (firmware, 
> modinfo), so it's signed for "firmware X on PCI:8086,1114 or "firmware Y on 
> ACPI:0A1D"

Should work as long as the HW IDs can't be tampered with.

> I want to understand the model, who signs what, and what security is allegedly 
> provided over the existing. If there are users sufficiently paranoid to 
> believe that signing firmware saves them, then fine. For most hardware it can 
> cut out some attackers, although anyone with sufficient money or a TLA can no 
> doubt just tap someone on the shoulder and say you are signing this for us.

That's always the case with security, root/chain of trust, etc.  There's always 
someone with bigger gun.  Most systems that aren't compromised are those that do 
not draw attention, mostly because of their insignificance.

> IMHO we want the supplier of a given firmware providing signatures on the 
> firmware git tree if this is done. A generic linux-firmware owned key would be 
> both a horrendously inviting attack target, and a single point of failure.
>
> Git can already do all the needed commit signing bits unless I'm missing 
> something here ?

If i read the above correctly you propose to have a tree where all binary blobs 
(or whatever data) will be trusted, because their authenticity will be verified 
prior to their inclusion?  By cloning this tree i should also trust its content 
because GIT takes care of data's integrity?


		Petko

Re: [RFD] linux-firmware key arrangement for firmware signing

[Mimi Zohar]

On Tue, 2015-05-26 at 18:08 +0100, One Thousand Gnomes wrote:

> IMHO we want the supplier of a given firmware providing signatures on
> the firmware git tree if this is done. A generic linux-firmware owned key
> would be both a horrendously inviting attack target, and a single point of
> failure.
> 
> Git can already do all the needed commit signing bits unless I'm missing
> something here ?

Nice!  I haven't tried signing commits yet.  Assuming the signatures can
be extracted from git, the firmware blob git commit signature could be
stored either as a security xattr or appended (eg. similar to kernel
modules).  The end system owner could then make the decision to load the
associated public key or not.

Mimi

Re: [RFD] linux-firmware key arrangement for firmware signing

[David Howells]

One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote:

> Ie you need to sign something more than the firmware, such as (firmware,
> modinfo), so it's signed for "firmware X on PCI:8086,1114 or "firmware Y
> on ACPI:0A1D"

I'm suggesting that we use the name string passed to request_firmware().

> IMHO we want the supplier of a given firmware providing signatures on
> the firmware git tree if this is done. A generic linux-firmware owned key
> would be both a horrendously inviting attack target, and a single point of
> failure.
> 
> Git can already do all the needed commit signing bits unless I'm missing
> something here ?

How does this help the kernel check that it's been given the right firmware
blob for its request?  Unless you compile into the kernel a list of hashes
compiled from the linux-firmware git head (or representative root hash) - in
which case we're back to Andy's hash list/hash tree approach with the problems
that that entails.

David

Re: [RFD] linux-firmware key arrangement for firmware signing

[Woodhouse, David]

[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]

On Thu, 2015-05-21 at 08:45 -0700, Greg Kroah-Hartman wrote:
> On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote:
> > Signatures don't provide any guarantees as to code quality or
> > correctness.   They do provide file integrity and provenance.  In
> > addition to the license and a Signed-off-by line, having the 
> > firmware provider include a signature of the firmware would be 
> > nice.
> 
> That would be "nice", but that's not going to be happening here, from
> what I can tell.  The firmware provider should be putting the signature
> inside the firmware image itself, and verifying it on the device, in
> order to properly "know" that it should be running that firmware.  The
> kernel shouldn't be involved here at all, as Alan pointed out.

In a lot of cases we have loadable firmware precisely to allow us to
reduce the cost of the hardware. Adding cryptographic capability in the
'load firmware' state of the device isn't really compatible with that
:)

In the case where kernel and modules are signed, it *is* useful for a
kernel device driver also to be able to validate that what it's about
to load into a device is authentic. Where 'authentic' will originally
just mean that it's come from the linux-firmware.git repository or the
same entity that built (and signed) the kernel, but actually I *do*
expect vendors who are actively maintaining the firmware images in
linux-firmware.git to start providing detached signatures of their own.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3437 bytes --]

Re: [RFD] linux-firmware key arrangement for firmware signing

[Mimi Zohar]

On Thu, 2015-05-21 at 16:03 +0000, Woodhouse, David wrote:
> On Thu, 2015-05-21 at 08:45 -0700, Greg Kroah-Hartman wrote:
> > On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote:
> > > Signatures don't provide any guarantees as to code quality or
> > > correctness.   They do provide file integrity and provenance.  In
> > > addition to the license and a Signed-off-by line, having the 
> > > firmware provider include a signature of the firmware would be 
> > > nice.
> > 
> > That would be "nice", but that's not going to be happening here, from
> > what I can tell.  The firmware provider should be putting the signature
> > inside the firmware image itself, and verifying it on the device, in
> > order to properly "know" that it should be running that firmware.  The
> > kernel shouldn't be involved here at all, as Alan pointed out.
> 
> In a lot of cases we have loadable firmware precisely to allow us to
> reduce the cost of the hardware. Adding cryptographic capability in the
> 'load firmware' state of the device isn't really compatible with that
> :)
> 
> In the case where kernel and modules are signed, it *is* useful for a
> kernel device driver also to be able to validate that what it's about
> to load into a device is authentic. Where 'authentic' will originally
> just mean that it's come from the linux-firmware.git repository or the
> same entity that built (and signed) the kernel, but actually I *do*
> expect vendors who are actively maintaining the firmware images in
> linux-firmware.git to start providing detached signatures of their own.

That's great!  What format do you expect the detached signatures to be?
Where will they reside?

Mimi

Re: [RFD] linux-firmware key arrangement for firmware signing

[Woodhouse, David]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

On Thu, 2015-05-21 at 12:22 -0400, Mimi Zohar wrote:
> 
> That's great!  What format do you expect the detached signatures to 
> be?
> Where will they reside?

Well, it kind of depends how things stand when the dust settles, but I
suppose the current plan would be to have .p7s files next to the
binaries in the linux-firmware.git repository.

-- 
                  Sent with Evolution's ActiveSync support.

David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3437 bytes --]

Re: [RFD] linux-firmware key arrangement for firmware signing

[gregkh]

On Thu, May 21, 2015 at 04:03:02PM +0000, Woodhouse, David wrote:
> On Thu, 2015-05-21 at 08:45 -0700, Greg Kroah-Hartman wrote:
> > On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote:
> > > Signatures don't provide any guarantees as to code quality or
> > > correctness.   They do provide file integrity and provenance.  In
> > > addition to the license and a Signed-off-by line, having the 
> > > firmware provider include a signature of the firmware would be 
> > > nice.
> > 
> > That would be "nice", but that's not going to be happening here, from
> > what I can tell.  The firmware provider should be putting the signature
> > inside the firmware image itself, and verifying it on the device, in
> > order to properly "know" that it should be running that firmware.  The
> > kernel shouldn't be involved here at all, as Alan pointed out.
> 
> In a lot of cases we have loadable firmware precisely to allow us to
> reduce the cost of the hardware. Adding cryptographic capability in the
> 'load firmware' state of the device isn't really compatible with that
> :)

We do?  What devices want this?  That's really a bad hardware design to
trust the kernel to get all of this correct.

And I say this as someone who is currently working on a hardware design
that does just this for a very tiny device.  It's only a few hundred
bytes of firmware size to be able to do proper key verification that the
firmware image is correct and can be "trusted".

> In the case where kernel and modules are signed, it *is* useful for a
> kernel device driver also to be able to validate that what it's about
> to load into a device is authentic. Where 'authentic' will originally
> just mean that it's come from the linux-firmware.git repository or the
> same entity that built (and signed) the kernel, but actually I *do*
> expect vendors who are actively maintaining the firmware images in
> linux-firmware.git to start providing detached signatures of their own.

Again, why have a detached signature and not just part of the firmware
blob?  The device needs to be caring about this, not the kernel.

Do other operating systems have this type of "feature"?

As the kernel doesn't know/care about what the firmware blob really is,
I don't see why it should be caring about firmware signing as that's a
binary running on a separate "computer".  Do we want to take this
the next logical step further and start requiring networked devices to
attest their kernels are signed correctly before we can talk to them?

We do that, and we are back at the old ISDN nightmare :)

thanks,

greg k-h

Re: [RFD] linux-firmware key arrangement for firmware signing

[Petko Manolov]

On 15-05-21 10:02:36, gregkh@linuxfoundation.org wrote:
> On Thu, May 21, 2015 at 04:03:02PM +0000, Woodhouse, David wrote:
> > 
> > In a lot of cases we have loadable firmware precisely to allow us to
> > reduce the cost of the hardware. Adding cryptographic capability in the
> > 'load firmware' state of the device isn't really compatible with that
> > :)
> 
> We do?  What devices want this?  That's really a bad hardware design to trust 
> the kernel to get all of this correct.

Which means nearly all hardware we use today is badly designed... :)

> And I say this as someone who is currently working on a hardware design that 
> does just this for a very tiny device.  It's only a few hundred bytes of 
> firmware size to be able to do proper key verification that the firmware image 
> is correct and can be "trusted".

And a "few" more bytes for the hash algorithm along the one for asymmetric key 
computation and management. :)

> > In the case where kernel and modules are signed, it *is* useful for a kernel 
> > device driver also to be able to validate that what it's about to load into 
> > a device is authentic. Where 'authentic' will originally just mean that it's 
> > come from the linux-firmware.git repository or the same entity that built 
> > (and signed) the kernel, but actually I *do* expect vendors who are actively 
> > maintaining the firmware images in linux-firmware.git to start providing 
> > detached signatures of their own.
> 
> Again, why have a detached signature and not just part of the firmware blob?  
> The device needs to be caring about this, not the kernel.

In ideal world this is what should be done.  However, adding the simplest (read 
slowest) MD5 implementation requires a few K's of ram on 32bit cpu.  MD5 is 
dead.  So we need SHA-something, which isn't smaller in terms of code size.  Add 
the asymmetric cryptography to the picture and we've already put away all 
vendors.

> As the kernel doesn't know/care about what the firmware blob really is, I 
> don't see why it should be caring about firmware signing as that's a binary 
> running on a separate "computer".  Do we want to take this the next logical 
> step further and start requiring networked devices to attest their kernels are 
> signed correctly before we can talk to them?

I think it is enough for you to know that your iwlwifi's firmware comes from 
Intel and not from a random Internet punk.  If you trust Intel with your wifi 
adapter you probably trust them to write good firmware for it.


		Petko

Re: [RFD] linux-firmware key arrangement for firmware signing

[Luis R. Rodriguez]

On Thu, May 21, 2015 at 10:02:36AM -0700, gregkh@linuxfoundation.org wrote:
> On Thu, May 21, 2015 at 04:03:02PM +0000, Woodhouse, David wrote:
> > On Thu, 2015-05-21 at 08:45 -0700, Greg Kroah-Hartman wrote:
> > > On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote:
> > > > Signatures don't provide any guarantees as to code quality or
> > > > correctness.   They do provide file integrity and provenance.  In
> > > > addition to the license and a Signed-off-by line, having the 
> > > > firmware provider include a signature of the firmware would be 
> > > > nice.
> > > 
> > > That would be "nice", but that's not going to be happening here, from
> > > what I can tell.  The firmware provider should be putting the signature
> > > inside the firmware image itself, and verifying it on the device, in
> > > order to properly "know" that it should be running that firmware.  The
> > > kernel shouldn't be involved here at all, as Alan pointed out.
> > 
> > In a lot of cases we have loadable firmware precisely to allow us to
> > reduce the cost of the hardware. Adding cryptographic capability in the
> > 'load firmware' state of the device isn't really compatible with that
> > :)
> 
> We do?  What devices want this?  That's really a bad hardware design to
> trust the kernel to get all of this correct.

On the 802.11 front its a CPU cost analysis issue Vs device CPU cost.  Atheros
for a long time found the device CPU too costly, while keeping a full ASIC
design the cheapest solution. Part of the issue with not using a device CPU
however is power consumption issues and if you are combining technologies
(for instance in the beginning 802.11 and Bluetooth) this becomes a practicel
impossibility as folks tend to end up preferring single-chip solutions. As
David alludes to though the more requirements you have on device CPU
functionality the costlier they will be, it would certainly be unfair to say
that relying on software signature verification would be a mistake, that's
pretty subjective. We should enable the market to do what it wishes and enable
the best solution to win. I do believe having this option can make Linux more
flexible.

There another side to this too, firmware signing is not just about getting
a vendor's own firmware to load. There's a bit of political game here I can
argue for here which IMHO can enable winning an argument for open firmware.
As I noted in my other thread there is somewhat of a dog and pony show to
this, but yet there is still some technical merit to it all as well. Let
folks doing the dog and pony show keep dancing -- one argument I can use
to help make a case for open firmware here, for instance is that like
with CFG80211_CERTIFICATION_ONUS we should be able to have developers opt
in to wish to use their own firmare. One can argue whether or not that
should enable one to win an argument over open firmware, but given I've
made these arguments before and I succeeded with open firmware, I do
believe it can help. Consider it part of a bag of tricks we need. Another
gain here is that if you do go with fw signing you do need a signature on
it, and well if distros only carry what is on linux-firmware, and if say
linux-firmware only has reasonable licensing practices in place *cough*,
well then -- some vendors better consider their licensing practices...

> And I say this as someone who is currently working on a hardware design
> that does just this for a very tiny device.  It's only a few hundred
> bytes of firmware size to be able to do proper key verification that the
> firmware image is correct and can be "trusted".

Sounds like a great project if you have the freedom and flexibility to
enable such hardware component. Now, if you can save a few bucks on it
per unit, how much would it be exactly? Just curious.

> > In the case where kernel and modules are signed, it *is* useful for a
> > kernel device driver also to be able to validate that what it's about
> > to load into a device is authentic. Where 'authentic' will originally
> > just mean that it's come from the linux-firmware.git repository or the
> > same entity that built (and signed) the kernel, but actually I *do*
> > expect vendors who are actively maintaining the firmware images in
> > linux-firmware.git to start providing detached signatures of their own.
> 
> Again, why have a detached signature and not just part of the firmware
> blob?

We can have both. If a device wants to use crypto hw signature checks,
let them, the file signature check thing can be for software solutions.
Alternatively if a vendor wanted to split the firmware binary from the
signature too and use it for hw crypto they can still do so. At least
for software separating the fw signature from the binary helps with
licensing. I am not sure if this can help with hw crypto solutions.

> The device needs to be caring about this, not the kernel.

Is that subjective?

> Do other operating systems have this type of "feature"?

Why follow? No one has CRDA, but then again, IMHO other OS solutions have
shit solutions for regulatory.

> As the kernel doesn't know/care about what the firmware blob really is,

Ah but it can. Consider open firmware solutions, and Kyle also happens
to be the maintainer of linux-firmware, so I wouldn't want to run a fimware
that didn't go through the policies set in place for linux-firmware.

> I don't see why it should be caring about firmware signing as that's a
> binary running on a separate "computer".

Provenance and integrity, and linux-firmware as the gate, while Kyle is
the gatekeeper.

> Do we want to take this
> the next logical step further and start requiring networked devices to
> attest their kernels are signed correctly before we can talk to them?

Wow. I'm glad I haven't had to deal with this political dog and pony
show concern.

> We do that, and we are back at the old ISDN nightmare :)

Someone thought of this for ISDN ?

 Luis

Re: [RFD] linux-firmware key arrangement for firmware signing

[Luis R. Rodriguez]

On Thu, May 21, 2015 at 11:23 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> Sounds like a great project if you have the freedom and flexibility to
> enable such hardware component. Now, if you can save a few bucks on it
> per unit, how much would it be exactly? Just curious.

Also, another thing to think about:

How many crypto checking devices do you need? If your motherboard
already comes with one, why not trust / rely on it once for all device
firmware? I realize silicon folks want to sell you kitchen sinks with
granite counter tops included, but if working on spiffy open designs,
I figure having the freedom to trust / rely on some other device's
components might yield pretty cheap and flexible solutions.

 Luis

Re: [RFD] linux-firmware key arrangement for firmware signing

[Woodhouse, David]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

On Thu, 2015-05-21 at 10:02 -0700, gregkh@linuxfoundation.org wrote:
> 
> Again, why have a detached signature and not just part of the firmware
> blob?  The device needs to be caring about this, not the kernel.
> 
> Do other operating systems have this type of "feature"?

Yes. Windows effectively does by virtue of the fact that it ships he
firmware *with* the driver and even if it's in a separate file (which
it often isn't), the signed manifest covers it all together.

Look at it this way: If you don't have an IOMMU, then signing modules
is *utterly* pointless unless you also sign firmware. A rogue device
can do *anything*.

We really do want firmware signing for the *OS*, not just for
regulatory issues and other vendor-interest stuff which was Luis's
original focus.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3437 bytes --]

Re: [RFD] linux-firmware key arrangement for firmware signing

[Luis R. Rodriguez]

On Thu, May 21, 2015 at 04:03:02PM +0000, Woodhouse, David wrote:
> On Thu, 2015-05-21 at 08:45 -0700, Greg Kroah-Hartman wrote:
> > On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote:
> > > Signatures don't provide any guarantees as to code quality or
> > > correctness.   They do provide file integrity and provenance.  In
> > > addition to the license and a Signed-off-by line, having the 
> > > firmware provider include a signature of the firmware would be 
> > > nice.
> > 
> > That would be "nice", but that's not going to be happening here, from
> > what I can tell.  The firmware provider should be putting the signature
> > inside the firmware image itself, and verifying it on the device, in
> > order to properly "know" that it should be running that firmware.  The
> > kernel shouldn't be involved here at all, as Alan pointed out.
> 
> In a lot of cases we have loadable firmware precisely to allow us to
> reduce the cost of the hardware. Adding cryptographic capability in the
> 'load firmware' state of the device isn't really compatible with that
> :)

Standards aside -- using crypto functionality on hardware or software are best
practices quite a few folks are picking up. Now, let me remind us that it was
crypto practices in software which in the end allowed us to gain huge corporate
support on the uphill battle to find vendors to start becoming friendly on
working with us upstream on the 802.11 front on Linux.  To be crystal clear,
although providing signature check support for file integrity and provenance
checks might seem like a "dog and pony show" [0] it nevertheless helped us
hugely upstream. For those that wish to side on the "dog and pony show" side
of the argument you have the freedom to do that, and should always have that.
In the end, that flexibility and maintaining peoples freedom's completely
(see CFG80211_CERTIFICATION_ONUS) are IMHO the best form of compromises we
can make for both camps.

There's two sides to the topic at hand:

1) Technical merit
2) Political merit

We went down the road of using some aspects of 1) to win on 2), I can say with
confidence that this was the case for 802.11 to the extend we even now have today
GPLv2 open firmware on linux-firmware. That was a huge win considering we lacked
most vendor support in the beginning. Not sure if something similar is applicable
to modules, there must've been some good amount of 2) and 1) to get it upstream
into Linux after all, I frankly don't care, but I suspect there must be some of it.

Since I can only speak on behalf of one side of the historical aspects of this
from a practical point of view I think we should look at this problem as ensuring
we do what we need to allow us developers to get the job done while folks working
on the political front figure what the fuck is needed from 1) to win 2) -- so long
as they keep our freedoms in mind. Although a few folks trimmed my original
comments about original motivation for this signature checking effort its important
to remind folks on the thread that the original motivation for all this was to
simply come together on a unified solution for both *modules* and 802.11 regulatory
for 2) and 1). On the 802.11 front CRDA has historically been very useful, but
since the kernel got module signature check support we can simply do away with
our own subsystem specific practices and file redistribution mechanism by unifying
our efforts on firmware with file integrity / provenance.

So the quest here is not to shove down folk's distribution's practices or beliefs
but rather simplify things for 802.11 and upkeeping the same flexibility to let
folks enable / disable things. So please keep in mind if you argue over signed
firmware as a solution to replace CRDA upstream, I'd like to also hear an
alternative to do away with it. I don't think expecting folks to use IMA is a
good option yet, from what I had reviewed so far.

So we have 2) and 1) for modules. We have 2) and 1) for 802.11. The goal here
was to simplify redistribution / code by sharing while keeping everyone's
freedoms to ignore all this as well.

Since the focus is to use the technical solution on modules, I think folks are
*seriously* confusing the issues on the technical front with the political. This
is bad! Those folks should simply write their alternative solutions and APIs
if we do not have them yet. What makes this problem harder is we now also have
IMA and LSM and even LSM stacking come to our future Linux tree, this allows
even more flexibility, and IMHO gets folks barking up the wrong trees [1].

What makes thing even more difficult is folks are arguing we now revisit
the technical aspects for modules using IMA while we have other folks
extending the old module technical solution. I think we can have a reasonable
compromise on all fronts here, but this requires a bit more review. Without
completing this review -- I'll prematurely say then that it would seem we could
keep everyone happy by enabling the existing extensions to module signing
to use PKCS#7 while folks who disagree with this figure out what path to
make the decision of what technical solution to use here configurable. Without
a final review on my part I'm inclined to believe we can accomplish this easily
with LSM stacking, by having module signature checks be:

a) optional
b) an LSM module can provide its own file integrity checks
c) the above can provide APIs that can be used for both modules and firmware

We actually already have an LSM hook for modules and firmware so technically
this should already be all possible, and folk who do not want PKCS#7 should
simply disable that stuff. Long term it may make sense to just LSM'ify it.

I believe this would be the right approach because we already went down the
module signing path and folks still working on that due to 1) or 2) are just
extending and perfecting that. Meanwhile, on the 802.11 front we're just trying
to simplify and unify things while keeping folk's beliefs on the dog and pony
show in mind.

> In the case where kernel and modules are signed, it *is* useful for a
> kernel device driver also to be able to validate that what it's about
> to load into a device is authentic. Where 'authentic' will originally
> just mean that it's come from the linux-firmware.git repository or the
> same entity that built (and signed) the kernel, but actually I *do*
> expect vendors who are actively maintaining the firmware images in
> linux-firmware.git to start providing detached signatures of their own.

Although we originally did not discuss this as firmware signature check support
was being fleshed out, I do believe this makes sense and as much dog and pony
show folks want to call this I do believe it will also help us with vendor
support. To this day I can say with a very straight face I believe Linux has
the best regulatory solution on the planet, perhaps this is of little value to
some folks, but I dealt with the politics first hand, I also *know* we have a
great track record to this day on Linux, let's keep it that way and see what
things we can do to make things easier for those technical folks trying to
iron out the politics for us. Now if you want to argue about the political 
aspects of any of this, you can do so, but this is perhaps not the best venue.
We can avoid those issues ourselves by enabling those we trust to create
flexibility to enable the differing leading technical solutions.

[0] https://en.wikipedia.org/wiki/Dog_and_pony_show
[1] https://en.wikipedia.org/wiki/Barking_up_the_wrong_tree

  Luis

Re: [RFD] linux-firmware key arrangement for firmware signing

[Petko Manolov]

On 15-05-20 23:14:53, Greg Kroah-Hartman wrote:
> 
> Ok, but how do we know "where"?  Who is going to start signing and attesting 
> to the validity of all of the firmware images in the linux-firmware tree 
> suddenly?  Why is it the kernel's job to attest this "where"?  Shouldn't your 
> distro/manufacturer be doing that as part of their "put this file on this 
> disk" responsibilities (i.e. the package manager?)

I did not say the kernel should care about signatures.  This is entirely user's
choice.  You care about authenticity, you require signature and verify it
against "known good" certificate. s/you/distro/

I'm just saying that it would be nice to have this feature in case somebody need 
it.  Luckily IMA has this functionality, although you'll have to work hard to 
get to use it. :)

> What is verifying a firmware image signature in the kernel attesting that 
> isn't already known in userspace?

The kernel is a lot better place to keep certificates and keys safe, compared to 
userland.


		Petko

Re: [RFD] linux-firmware key arrangement for firmware signing

[Luis R. Rodriguez]

On Wed, May 20, 2015 at 05:24:46PM +0100, One Thousand Gnomes wrote:
> On Wed, 20 May 2015 09:04:26 -0500
> Seth Forshee <seth.forshee@canonical.com> wrote:
> 
> > On Tue, May 19, 2015 at 10:02:32PM +0200, Luis R. Rodriguez wrote:
> > > This begs the question on how we'd manage keys for firmware signing on
> > > linux-firmare. Since the keys are x509 keys we need a CA. Based on some initial
> > > discussions it would seem we'd need the Linux Foundation to create a key, this
> > > would be embedded in the kernel and that key would be used to sign Kyle's key.
> > > Kyle would in turn use his key for signing linux-firmware files. David, Kyle,
> > > did I summarize this correctly ?
> > 
> > I raised the question of key revocation when we discussed this on irc,
> > but it wasn't answered to my satisfaction. If a key signed by the
> > kernel-embedded key is compromised, how can that key be revoked so that
> > it is no longer trusted?
> > 
> > Someone mentioned UEFI blacklists, which I don't know much about, but
> > not all systems have UEFI. The only reliable option that comes to mind
> > for me is an in-kernel blacklist of keys which should no longer be
> > trusted.
> 
> More to the point why do you want to sign firmware files ?

This would add support to firmware loading the same dog and pony show as used
by the module and kexec code, sharing as much dog and pony as is possible. This
also allows us to phase 802.11's dog and pony show which is sitting on the side all
on it own and implicates distros to do more work.

 Luis

Re: [RFD] linux-firmware key arrangement for firmware signing

[Kyle McMartin]

On Wed, May 20, 2015 at 09:04:26AM -0500, Seth Forshee wrote:
> I raised the question of key revocation when we discussed this on irc,
> but it wasn't answered to my satisfaction. If a key signed by the
> kernel-embedded key is compromised, how can that key be revoked so that
> it is no longer trusted?
> 
> Someone mentioned UEFI blacklists, which I don't know much about, but
> not all systems have UEFI. The only reliable option that comes to mind
> for me is an in-kernel blacklist of keys which should no longer be
> trusted.
> 

I think the solution here is two-fold... first, we'll probably try some
to use a HSM for signing, so there's extremely low risk of compromise.
Secondly, if we annotate the key such that it can only be used for
firmware, a compromise of my key won't allow you to kexec or load kernel
modules.

regards, --Kyle

Re: [RFD] linux-firmware key arrangement for firmware signing

[David Howells]

Luis R. Rodriguez <mcgrof@suse.com> wrote:

> This begs the question on how we'd manage keys for firmware signing on
> linux-firmare. Since the keys are x509 keys we need a CA. Based on some
> initial discussions it would seem we'd need the Linux Foundation to create a
> key, this would be embedded in the kernel and that key would be used to sign
> Kyle's key.  Kyle would in turn use his key for signing linux-firmware
> files. David, Kyle, did I summarize this correctly ?

Yes.

> I think we need one change here, we'd need to ensure that such key could
> only be used for vetting firmware files, not modules loaded.  The
> firmware_class could for instance still use all the keys in
> system_trusted_keyring, which would include the UEFI key db, but it does not
> seems reasonable to expect keys used for fw signing to also go into
> system_trusted_keyring to also be used for module signing.

X.509 certificates can take attributes that define what the key held therein
may be used for.

You actually have four categories of key usage, I think:

 (1) Signing modules.

 (2) Signing firmware.

 (3) Signing kernel binaries for kexec.

 (4) Signing other keys that can then be chained to (1) - (3).

For instance, the LF might use their key to sign Kyle's key.  Kyle might want
to replace his key yearly, say, because the more examples of things signed
with it, the more exposed it becomes.  So the kernel would need to carry the
LF key, say, and then the appropriate one of Kyle's keys could be loaded
dynamically.

David