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

[Jason Cooper <jason@lakedaemon.net>]

On Wed, Aug 03, 2016 at 10:20:17AM -0700, Andy Lutomirski wrote:
> On Wed, Aug 3, 2016 at 9:44 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> > On Tue, Aug 02, 2016 at 08:07:17AM -0700, Andy Lutomirski wrote:
...
> >> But we do need the kernel to verify the "iwlwifi-whatever.ucode" string to
> >> prevent an attack in which someone does:
> >>
> >> cp other-signed-thing.ucode iwlwifi-whatever.ucode
> >
> > How so?  The sha256 of the blob won't match, the signature will fail.
> >
> 
> I'm assuming the attacker has the ability to validly sign
> other-signed-thing.ucode.  For example, suppose that Eviltel wanted to
> compromise Intel hardware and released a firmware blob that worked
> correctly on Eviltel hardware but did bad things if loaded into an
> Intel card.  The verification scheme should prevent Kyle's signature
> on the Eviltel blob from being abused to load it into the Intel
> device.

Ah, now I see.  I was missing the Eviltel bit. ;-)  So you're attempting
to mitigate one of the key weaknesses of the CA system.  I still don't
think the filename is the correct mechanism for what you're trying to
do.  Although, I agree that it does need to be addressed and mitigated.

Perhaps the PCI ids and USB ids would be a better discriminator?  So,
your signature struct would contain one or more vendor/product
identifiers for which the signed blob is valid.  On embedded, the
devicetree compatible string may be sufficient for non-discoverable
busses.

In a realistic scenario, I could see Intel just signing the firmware,
then 'we' counter-sign with the added metadata restricting the firmware
to a specific subset of devices.  iow, we need to make sure to separate
veracity "Intel did create this" from policy "Debian/LKML says this
firmware should only be loaded into [device list]"

thx,

Jason.