ephemeral key used to sign mokmanager should have better certificate attributes

[Dimitri John Ledkov]

I try to boot mokmanager. It fails to boot, as it's not signed with canonical online key, chained to canonical CA, which shim tries to validate and fails. I see scary blue screen of death with validation errors.

# sbverify --list /boot/efi/EFI/ubuntu/mmx64.efi
warning: data remaining[1114272 vs 1269496]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /C=US/L=SomeCity/O=SomeOrg
image signature certificates:
 - subject: /C=US/L=SomeCity/O=SomeOrg/CN=shim
   issuer: /C=US/L=SomeCity/O=SomeOrg

shouldn't shim builds, submit shix64.efi mmx64.efi for Canonical online key signing?

Maybe as separate shim-canonical & shim-canonical-signed packages, which chain off src:shim? (since we can't easily rebuild shim)

[Dimitri John Ledkov (xnox)]

mmx64.efi uses ephemeral key

which is a bit scary, as the cert is unknown and doesn't indicate at all that it is ephemeral.

[Dimitri John Ledkov (xnox)]

I would prefer we enabled vendor signing of mmx64.efi

[Chris Coulson (chrisccoulson)]

This isn't really any different to how kernel module signing is handled though - is there any real benefit to adding the extra step of signing mmx64.efi (and fbx64.efi) with the vendor key, other than not having to keep shimx64.efi, mmx64.efi and fbx64.efi in sync if you're testing a local build?

[Steve Langasek (vorlon)]

mokmanager is part of shim and you should always have the matching versions of mmx64.efi and shimx64.efi on the ESP, so the use of ephemeral vs archive key is not material at runtime for a properly-installed system. Reducing the overall number of asset types signed directly with the online signing key is preferable in terms of management of our key hierarchy. And if we were to sign it directly with the archive key, I would want it split out of the shim package entirely and treated as a separate source, with a separate upload and signing cycle - which is a lot of extra work for very little benefit.

If the issue is that the description on the ephemeral certificate is opaque, that is something we could address in the shim source instead.

Currently:

$ openssl pkcs7 -noout -print_certs -inform DER -in /tmp/detached.der
subject=C = US, L = SomeCity, O = SomeOrg, CN = shim

issuer=C = US, L = SomeCity, O = SomeOrg

$

I can see how we might want to improve on that.

[Dimitri John Ledkov (xnox)]

I guess my general level of paranoia w.r.t number of roots of trust, and ability to inspect them.

Improved subject would help a lot.

Can that shim cert sign online signing subkeys? Can the shim cert sign grub? Kernel? Kernel Modules? Are the questions I don't even want to think about.

[Steve Langasek (vorlon)]

On Fri, May 22, 2020 at 05:38:40PM -0000, Dimitri John Ledkov wrote:
> I guess my general level of paranoia w.r.t number of roots of trust, and
> ability to inspect them.

> Improved subject would help a lot.

> Can that shim cert sign online signing subkeys? Can the shim cert sign
> grub? Kernel? Kernel Modules? Are the questions I don't even want to
> think about.

$ openssl pkcs7 -noout -print_certs -text -inform DER -in /tmp/detach.der
[...]
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Key Agreement, Certificate Sign, CRL Sign, Encipher Only, Decipher Only
            X509v3 Extended Key Usage:
                Code Signing, Microsoft Trust List Signing
            X509v3 Basic Constraints:
                CA:FALSE
[...]

It cannot sign subkeys.

If it signed any of grub, kernel, or kernel modules, it would be trusted.
However since it is an ephemeral key that's thrown away after the build,
this would not happen. And it would be pointless to try to limit what could
be signed with this key, given that it is already used to sign EFI binaries,
which is the highest level of trust.

[Jeff Squyres (jsquyres-cisco)]

Per @vorlorn's and @xnox's suggestions, I opened a merge request with better subject lines for the ephemeral certificate. Could someone have a look?

https://code.launchpad.net/~jsquyres-cisco/ubuntu/+source/shim/+git/shim/+merge/395923

Many thanks.

[Steve Langasek (vorlon)]

This is resolved by virtue of the fact that we now don't ship an ephemerally-signed mokmanager, but sign it instead with the archive key.