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

David Woodhouse dwmw2 at infradead.org
Tue Aug 2 14:09:03 UTC 2016


On Tue, 2016-08-02 at 14:00 +0000, Jason Cooper wrote:
> 
> You're actually hitting at the core of the problem.  The CA system
> (Thawte, Verisign, etc) is better than what came before it.  We now have
> enough experience with it, and have seen the band-aids [0], to know we need
> something better.
> 
> The problem here is that we (users) need to be able to verify that
> iwlwifi-whatever.ucode claimed to be created by Intel, was indeed the
> *same* one Intel shipped out the door.  That's it.  It's up to the user
> to decide to "trust" Intel's microcode or not.  All the kernel should be
> doing is confirming cryptographically that it came from Intel.
> 
> Now, the CA vice Web-of-trust question is "Is this public key the proper
> public key for Intel?"  There's several ways to solve this, and they
> aren't mutually exclusive:
> 
>  - Use the CA to verify you have the correct key
>  - Use PGP counter-signing to sign Intel's key (kernel devs could do
>    this according to pre-determined authenticity criteria)
>  - Use TOFU (Trust on First Use) to confirm that your firmware file is
>    signed with the *same* key for each subsequent version
>  - Use crowd-sourcing to confirm that everyone else has the same public
>    key for Intel
> 
> Each approach has it's pluses and minuses, so a combination of
> approaches is probably the most viable.

The simple solution which had been proposed was to add a variant of
request_firmware() which specified the key(s) which were acceptable for
signing the firmware in question.

So Intel's signing key would be "trusted" merely by virtue of the fact
that it is explicitly referenced by the iwlwifi driver.

If you are able to get changes to the iwlwifi driver accepted by Linus,
then you can change that. But then, if you can sneak bogus changes into
the drivers then you have other attack models anyway, so I don't think
we need to invent more trust schemes to avoid that.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20160802/1cf8f6f7/attachment-0001.bin>


More information about the Ksummit-discuss mailing list