Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski <luto@amacapital.net>]

On Wed, Aug 12, 2015 at 11:22 AM, David Howells <dhowells@redhat.com> wrote:
> Andy Lutomirski <luto@amacapital.net> wrote:
>
>> > The top patch here:
>> >
>> >         http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7-2
>> >
>> > allows demand loading of keys based on their SKID into a special keyring from
>> > which they get erased after an arbitrary 3 minutes of existence.  This key can
>> > then be used to verify a signature instead of using the primary system keyring
>> > used for module signature checking.
>> >
>> > Building on this, a driver could have a SKID compiled into it which could then
>> > be used to load a key for request_firmware() to use in verifying the blobs
>> > that that driver requires.
>> >
>>
>> Who signs the vendor key?
>
> From the arguments so far presented, the vendor - but possibly allowing the
> linux-fimrware manager to sign in lieu if the admin of a machine running this
> stuff allows it.

The device vendor?

How do you plan on requesting a self-signed vendor key with any kind
of security if there isn't some root of trust in the kernel.

>
>> Why are we bothering loading device vendor keys into a keyring in the
>> first place?
>
> Caching.  Some drivers need more than one firmware blob.
>
>> Why not just have an API to request firmware either signed by a literal key
>> provided by the driver *or* whatever keys the system trusts in general for
>> firmware signing?
>
> By "a literal key provided by the driver" I presume you mean that the parts of
> the key (perhaps an X.509 cert) are actually compiled into the driver.  Yes we
> could do this quite easily - key_create_or_update() will turn a binary key
> blob into a struct key * that can then be used.  Do we want ~1.5K or more of
> undiscardable data per key adding to each module that wants to load firmware,
> particularly if it needs to carry several keys just in case one gets revoked?

1.5K?  I'm talking about an actual raw public key, which is 65 bytes
or less in reasonable implementations.  (64 or 65 bytes for P-256
depending on encoding and 32 bytes for compressed schemes like EdDSA.)

--Andy