On Wed, Aug 14, 2019 at 08:35:57AM -0400, Paul Moore wrote:
> On Tue, Aug 13, 2019 at 2:03 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote:
> > On 8/12/19 8:35 AM, Josh Boyer wrote:
> > > On Mon, Aug 12, 2019 at 11:23 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > >> On Fri, Aug 9, 2019 at 8:31 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > >>>
> > >>> Hello all,
> > >>>
> > >>> I'm not sure if this is the place for this, but if not perhaps you
> > >>> could point me in the right direction?
> > >>>
> > >>> I'm looking for the certificate associated with the key used to sign
> > >>> the Fedora kernels for UEFI Secure Boot. What little information I've
> > >>> found indicates that it should be part of the "shim" package sources,
> >
> > Well, you likely want to look at the pesign package for the signing
> > information, but the cert isn't in there either. It's in smart cards
> > attached to kernel builder machines. When the kernel builds on those the
> > spec sees that and uses pesign to sign them, otherwise it uses a 'test'
> > cert to sign things.
> >
> > May I ask why you want the cert?
>
> I'm working on extensions to tboot to support kernel signatures
> instead of hashes. Not wanting to reinvent the wheel I figured I
> would reuse the signed PECOFF format used by UEFI Secure Boot; the
> Fedora kernels are one of the kernels I've been using for testing.
Why? Just throw tboot into the sea already. It's completely
incompatible with the concept of a real chain of trust for booting.
> While it is still a work in progress, I will be presenting on this
> topic next week at LSS-NA.
>
> > >>> but it isn't there, and looking back and random points in it's history
> > >>> I can't seem to find it. I've found the CA used to sign this mystery
> > >>> certificate, but not the kernel's signing certificate. Any help you
> > >>> can provide would be appreciated.
> > >>>
> > >>> For reference, this is the certificate I'm looking for:
> > >>>
> > >>> Signer #0:
> > >>> Subject: /CN=Fedora Secure Boot Signer
> > >>> Issuer : /CN=Fedora Secure Boot CA
> > >>> Serial : 9976F70F
> > >>>
> > >>> ... and no, I'm obviously not asking for the private key, just an
> > >>> authoritative source for the public key certificate :)
> >
> > We don't have one currently, because I guess we didn't think this would
> > be of use to anyone. If there is some use case for it to be published,
> > we can do so...
>
> It seems like one would want to publish the certificates used to sign
> their kernel images, at the very least publish the CA if not the
> entire chain.
The CA cert is in dist-git in the shim-unsigned-x64 package, which more
or less has to be the authoritative source. When we start signing
aarch64 binaries for real there will be another one in
shim-unsigned-aarch64 (sorry about the nomenclature mismatch in the
naming.) Also see my other email where I've given you a url. I'll put
other arches there too, and add new certs whenever we cycle them
(looking like late this year for x86, but...), but I may need reminding.
There's just too much stuff to do in a day.
> Outside the kernel image itself, the only place I could find the
> "CN=Fedora Secure Boot CA" was in the signing request for the UEFI
> shim; I couldn't find the "CN=Fedora Secure Boot Signer" anywhere but
> the kernel image.
Yeah, we don't publish it because a) there's more than one in order to
make traceability and limiting access possible in the face of redundant
builders, and b) that's the cut-out point to make revocation halfway
sane. The chain is embedded in the signature, and the top level issuing
certificate is explicitly trusted in shim.
> Since I'm just doing dev/test at the moment I extracted the signing
> cert from the kernel image and I'm using that, but that isn't a
> good/general solution for a number of reasons.
>
> FWIW, once I have something that is working properly and suitable for
> upstreaming (it is still a prototype) I plan to work on getting it
> merged into the tboot upstream.
Is there a broader goal here? It would seem to be academically
interesting but fundamentally untrustable, because it's using tboot.
Unrelated to that, how are you planning to make revocation work in
tboot? Secure boot doesn't have revocation certificates, just a signed
list of revoked {one of: {hash,tbs-hash,cert-tbs-hash,certificate}}.
Where will revocations be stored, and how is that storage protected?
> However, regardless of my work on tboot, I think it would be nice to
> be able to verify a kernel signature without relying on the
> certificate chain stored within the kernel.
You realize that's how literally all signature verification works,
right? First verify the chain, then check everything in the
chain for revocation, then check everything in the chain for
authorization. You can interleave them, but you're still checking the
signature against the chain.
--
Peter
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
