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

[Andy Lutomirski <luto@amacapital.net>]

On Mon, Aug 1, 2016 at 1:57 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Mon, Aug 01, 2016 at 01:37:43PM -0700, Andy Lutomirski wrote:
>> On Mon, Aug 1, 2016 at 1:23 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
>> > The second stage of firmware singing would be to iron out if vendors even want
>> > to participate with a series of vendor + firmware file key and we'd have a
>> > registry in the kernel built-in. We'd check then provenance in 2 levels:
>> >
>> >   o linux-firmware maintainer key
>> >   o vendor key for the target file
>>
>> Given Johannes Berg's request to move regulatory database loading into
>> the kernel, there might be an earlier use case.
>
> I share his goal, and in fact getting rid of needing CRDA was my original
> motivation to add firmware signing support. When we reviewed how this would
> work -- we seemed to have agreed that Seth (wireless-regdb maintainer) would no
> longer need to sign the regulatory.bin file and whatever file we end up with
> would instead be signed by Kyle, the linux-firmware maintainer.

Sounds entirely reasonable.

>
>> Specifically, either
>> set up the regulatory database with a vendor of
>> "linux-wireless-regulatory" and teach the verification code that this
>> particular vendor *requires* a vendor signature (and not, say, a
>> distro signature) or allocate it its own enum value for the type and
>> teach the verification code to work with that.
>
> Well reason we ended up deciding on just one key and linux-firmware was
> that people already package linux-firmware and we'd hope no one will
> put a gun to Kyle's head to do evil things. Nevertheless, what you
> describe of augmenting keys for files / purpose seems sensible, however
> this should be optional. For our case in 802.11 we seemed to be OK
> with Kyle's key last we discussed.

Let me put on my security person / armchair cryptographer hat:

NAK NAK NAK NAK NAK

The 90s are over.  Saying "I threw together this protocol.  It has
these known weaknesses, but I don't think they really matter all that
much." was a pretty bad idea in the nineties (witness SSL2, SSL3, WEP,
etc), and IMNSHO it's simply inexcusable now.

David Howells implemented PKCS7 authenticated attribute support in the
kernel for a reason.  If Kyle will use PKCS7 signatures, get the
authenticated attribute format right and *use it* from day one.  Or he
could use my old suggestion instead: rather than signing the firmware
blob itself, sign a little data structure like this:

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.
};

Then, to verify a signature, the kernel hashes the blob, generates its
own linux_blob_signed_data, memcmps it to the one that Kyle signed
(and rejects if they differ *at all*), and then verifies the
signature.  (Do not try to be clever and parse the supplied
linux_blob_signed_data -- there is a long and storied history of
equivalent ideas being implemented incorrectly, and I can dig out
literature references if you really want.  Just generate your own and
memcmp it, which leaves no room for ambiguity.)

If you're using something other than PKCS7 (which I'd suggest -- PKCS7
is a nasty, ugly, overcomplicated standard), use the struct
linux_blob_signed_data approach.

This is only a few lines of code, and I think there is no excuse for
getting it wrong.  Heck, this would be trivial to implement in pretty
much any scripting language better than bash.

(Sorry to bash your signature thingy, Kyle, but all I'm asking you do
to is either use the fancy pkcs7 openssl options (*gag*) or sign a
trivial data structure instead of the file itself.  If you like, I
hereby offer to write the code if you give me a baseline to work
with.)

--Andy