[Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski]

On Aug 1, 2016 5:33 PM, "James Bottomley" <
James.Bottomley at hansenpartnership.com> wrote:
>
> On Mon, 2016-08-01 at 14:14 -0700, Andy Lutomirski wrote:
> > struct linux_blob_signed_data {
> >   unsigned char magic[8];  // "LINUXSIG" -- for domain separation in
> > case someone messes up
> >   uint32_t version;  // = 1
> >   unsigned char sha256[32];  // SHA256 hash of the blob
> >   uint32_t type;  // what type of thing this is (firmware, etc)
> >   unsigned char description[];  // the remainder of the structure is
> > "iwlwifi-whatever.ucode", etc.
> > };
>
> Where's the signature in this?  I see a hash but not a signature.

The whole structure is signed verbatim with your favorite algorithm.

>  However since you NAK'd them: now you're reinventing stuff pkcs7
> already has.  pkcs7 has ASN.1 encodings of the hash and the signature,
> so no need to repeat it in a non standard way.  In fact, since the
> kernel already understands pkcs7, why not just use it (DER encoded).
>  pkcs7 can do an attached and detached signature format, so we could
> just simply use it to package signed modules.

This approach solves none of the problems I'm solving.  Using PKCS#7 with
careful use of "authenticated attributes" does, if you're very careful, as
I mentioned upthread.

But PKCS#7 is a legacy mess, is only compatible with sensible modern
signature algorithms if appropriate ASN.1 bindings exist, is actively
insecure [1], and cannot be replaced by anything else in a drop-in manner
if you use authattrs.

Also, the PKCS#7 parser in the kernel is probably many times larger than a
simple verifier for basically any modern signature scheme.  In contrast, my
scheme is only a couple of lines plus the underlying verifier (RSA PKCS#1
or RSA-PSS or P-256 ECDSA or whatever).  And PKCS#7 isn't even needed for
FIPS compliance AFAIK.

AFAICT the only decent reason for supporting PKCS#7 in the kernel is for
compatibility with some Authenticode thing I never quite figured out the
use of.

[1] The authattr mechanism isn't internally domain-separated, so signatures
with authattrs can be used to generate valid signatures over invalid data.
I think David Howells worked around this in the kernel after I pointed it
out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20160801/fdda48d9/attachment.html>