[Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Wed, 2015-08-12 at 12:25 -0700, Andy Lutomirski wrote:
> On Wed, Aug 12, 2015 at 12:15 PM, James Bottomley
> <James.Bottomley at hansenpartnership.com> wrote:
> > On Wed, 2015-08-12 at 12:09 -0700, Andy Lutomirski wrote:
> >> On Wed, Aug 12, 2015 at 11:45 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> >> > On Wed, 2015-08-12 at 19:22 +0100, David Howells wrote:
> >> >> 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?
> >> >
> >> > No. Just use a *hash* of the acceptable signing cert(s)¹. Note that the
> >> > SKID is *usually* a hash of the public key, but isn't guaranteed to be
> >> > so, so using the SKID to specify the acceptable signing cert isn't
> >> > secure.
> >> >
> >> > The actual signing cert doesn't need to be present in full because we
> >> > can require it to be present in the PKCS#7 signature.
> >>
> >> Screw the cert.  It doesn't certify anything -- it's just a bloated
> >> wrapper around a public key.  It's not even worth the space in /lib it
> >> takes up.
> >
> > I don't think we can entirely do that.  I agree the kernel only needs to
> > know that the owner of the firmware root of trust is happy with the
> > public key to verify the firmware signature.  However, the owner of the
> > firmware root of trust might like to satisfy themselves that the key was
> > genuinely issued by the people who should be providing the firmware.  To
> > do that, they need to check the certificate chain.  I agree this can be
> > done in userspace and doesn't have to be done by the kernel.
> 
> I don't think it belongs in deployed userspace either.  This should be
> the distro's job, and we shouldn't have to care how the distro does
> it.  We have no business deciding whether $VENDOR's alleged public key
> is valid at runtime.

Users who don't trust (or build their own) distro tend to like to verify
these things themselves.  Even basic security would suggest that you
should check everything you can check yourself just in case the third
party were accidentally compromised.

> >> Once we're talking real, modern public keys, there's no point in even
> >> hashing them.  A good cryptosystem will have 32-byte public keys, and
> >> a sufficiently strong hash will be 32 bytes.  Maybe hashing makes a
> >> little bit of sense if we're stuck with RSA for some reason.
> >
> > I'm slightly confused by this comment: If you're thinking of Elliptic
> > Curve Cryptography, then it is simply RSA, just done over a more funky
> > mathematical structure that yields shorter keys.
> 
> Not quite.  ECC signatures are generally Schnorr-based (except ECDSA,
> which is kind of like a bastardized Schnorr signature that avoids the
> now-expired patent AUIU), but they're not based on exponentiation at
> all.
> 
> RSA signatures are (loosely) based on the idea that only the private
> key holder knows the period of exponentiation in the key pair's group.
> In ECC schemes, the group is generally a globally constant parameter,
> and the private key's holder doesn't know anything special about the
> group, so you need a different approach entirely.
> 
> All that's moot, though.  IMO the only reason we should support RSA
> here is if there are vendor keys already out there (or Authenticode,
> sigh) that use RSA.  RSA keys and signatures are rather large.

In either case security rests on the discrete log problem.

James