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

[Andy Lutomirski <luto@amacapital.net>]

On Tue, Jul 28, 2015 at 12:19 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Tue, 2015-07-28 at 10:03 -0700, Andy Lutomirski wrote:
>>
>> This will require that we take any firmware vendor's key and rewrap it
>> somehow into a new X.509 blob with a key usage constraint.
>
> There are established ways of handling those constraints as external
> objects (see how NSS does it in its trust tokens, and thus p11-kit
> -trust does too).

Wow, I thought X.509 was bad.  Now we get PKCS#11, too?  Ick.

I have no problem whatsoever with having the userspace tooling support
PKCS#11 tokens.  I think the kernel should try to minimize the extent
to which is depends on X.509 on the kernel side.

If we're going to load keys into the kernel (at compile time, from
UEFI, whatever), let's just *tell* the kernel, in plain English or C,
what those keys are for, rather than trying to parse X.509
constraints.

I'll point out that the Internet tried to use X.509 name constraints
to allow CAs to be constrained to subsets of the DNS space, and it
*still* doesn't work.

Heck, with the X.509 variant, if Megasoft has an existing key signed
by SketchyTrust, and we want to trust SketchyTrust to sign firmware
for SketchyUSB devices (and to delegate to Megasoft using the
*existing* key), are we supposed to enforce transitive constraints?
Where are they rooted?  I think this way lies madness.  Let's just
throw SketchyTrust's key in the "SketchyUSB only" pile and be done
with it rather than fiddling with OpenSSL to re-wrap SketchyTrust's
self-signed (?).

If I'm the unaffiliated author of a driver for a SketchyTrust device,
I want to throw the cert into my driver and be done with it.  The
kernel should *figure out on its own* that the cert is associated with
my driver and my driver only and can't sign for my GPU.  I really
don't want to muck with the X.509 blob, because I'm going to get it
wrong.

[1] If we start rewrapping root keys and shoving the X.509 blobs into
drivers, who signs those blobs?  We can't self-sign them because we
don't have the private key, and we don't really want a completely
pointless "kernel" key that exists solely for the purpose of producing
well-formed X.509 certs, and we probably don't want to use ill-formed
unsigned X.509 certs as our root.  So what's the point of using X.509
at all for this purpose?

--Andy