[Ksummit-discuss] Last minute nominations: mcgrof and toshi
Jason Cooper
jason at lakedaemon.net
Wed Aug 3 17:50:16 UTC 2016
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 at 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.
More information about the Ksummit-discuss
mailing list