Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi

[Linus Walleij <linus.walleij@linaro.org>]

On Tue, Aug 2, 2016 at 4:13 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2016-08-02 at 14:54 +0200, Linus Walleij wrote:

>> What I always intuitively felt is that I would be happy if the same
>> GPG keys we use for pull requests of kernel code would extend
>> to firmware signing, so that we move from the overall-industry
>> focus on legislative bodies (Thawte, ...) signing certificates with
>> OpenSSL and thus being the root of trust, over to putting the root
>> of trust for any software related to Linux into the same web of
>> trust that we already use for developing the code per se.
>
> This is the vision that Monkeysphere is based on
>
> http://web.monkeysphere.info/

That looks nice.

>> I would certainly trust a firmware signed by say Laurent Pinchart,
>> but not sure about one signed by E.Corp.
>
> Really?  Assuming E.Corp is the one actually producing the firmware,
> why would you say they're less qualified than Laurent to certify their
> own firmware.  Half the SCSI chips I see have proprietary firmware.
>  Even if I were willing to sign it, would you really trust my signature
> when I can't even decompile it?

I would trust an Intel WiFi driver if it was signed by Dirk Hohndel
or H. Peter Anvin whose GPG keys I have in my own web of trust
and work for Intel. And this is simply because I trust these guys
more than the corporate entity they work for.

And when you think of it, that is exactly what the kernel devs
web of trust is doing: we trust these individuals, not the companies
they work for. That is why we are using GPG keys and not
OpenSSL certificates signed by say Linux Foundation to send
our pull requests.

Well maybe I attribute intent where there is none: maybe the
GPG signature in git was just arbitrarily chosen for this, due to
it's availability and/or simplicity it could have been the other way
in a parallel universe that contributors would have to use
certificates signed by LF... I don't know. I'm uncertain.

But I percieve it as if there is some tension here between "our"
individual trust and the corporate trust in legal bodies. I might
be mistaken.

> ... and this is the problem with "trust" it's too fine
> grained to map into any network.  If the firmware is binary, why would
> you trust anyone other than the vendor who produced it to sign it.
>  What would such a signature even mean if someone else did?  However,
> if the firmware is actually open source, like the 53c700 or aic7xxx
> firmwares, which are both in the kernel source tree, perhaps you would
> trust me to sign it.

Being able to inspect the source is paramount and 53x700 and aic7xx
show what is needed if we want a future where we as (power) users can
trust our own devices. If I would recompile any of those two firmwares
myself I guess I would also sign them myself and trust myself.
The inroad to complete trust would be to first read the firmware source
code.

Yours,
Linus Walleij