Re: [RFD] linux-firmware key arrangement for firmware signing

[Petko Manolov]

On 15-05-26 18:08:13, One Thousand Gnomes wrote:
> On Thu, 21 May 2015 18:53:19 +0300
> Petko Manolov <petkan@xxxxxxxxxxxx> wrote:
> 
> > It is device's job to verify firmware's correctness.  It is user's job to 
> > verify vendor's identity.  Two different things, not related to each other.
> 
> The device verifies the firmwares identity. The firmware's correctness is 
> unknownable if the mathematicians are correct.

Or so the story goes... :)

Anyway, bad choice of words.  I meant to say its device's responsibility to 
verify binary blob's integrity, be it firmware or something else.

> The device will accept firmware signed in some manner with some key that is 
> probably part of a root of trust embedded deeply im the hardware itself. If 
> it's vendor X hardware then firmware not signed with the key for that hardware 
> won't work, and vendor X has the key locked away.

Ideally, this would be the case.  However, as far as i know there is very few 
devices out there that will do what you describe.  First, it is complex.  
Second, and more important, it is expensive.  Third, if the root of trust is 
compromised the device is done for.  Or rather its user.

Considering the above i guess this isn't going to happen anytime soon, except 
for highly specialized devices.  Of course i may not be correct.  In 
mathematical sense as well. :)

> It's also worth remembering most of the dumb non signature checking devices 
> are things like USB. They don't have access to the internals of the system so 
> their attack options are more limited.

Most devices just lack the infrastructure.  Especially those that are used in 
the embedded world.  Very few of them are designed to withstand relatively 
moderate attempt on their security.  Speaking about hardware.  Come the software, 
things are quickly getting messier.


> On Thu, 21 May 2015 16:03:02 +0000
> "Woodhouse, David" <david.woodhouse@xxxxxxxxx> wrote:
> 
> > In the case where kernel and modules are signed, it *is* useful for a kernel 
> > device driver also to be able to validate that what it's about to load into 
> > a device is authentic.
> 
> You also need to know its "authentic" for that specific device. Otherwise you 
> may be able to exploit something by loading an authentic firmware for another 
> piece of hardware.

Well, yes this may easily happen.  Integrity checks aren't going to help here.

> Ie you need to sign something more than the firmware, such as (firmware, 
> modinfo), so it's signed for "firmware X on PCI:8086,1114 or "firmware Y on 
> ACPI:0A1D"

Should work as long as the HW IDs can't be tampered with.

> I want to understand the model, who signs what, and what security is allegedly 
> provided over the existing. If there are users sufficiently paranoid to 
> believe that signing firmware saves them, then fine. For most hardware it can 
> cut out some attackers, although anyone with sufficient money or a TLA can no 
> doubt just tap someone on the shoulder and say you are signing this for us.

That's always the case with security, root/chain of trust, etc.  There's always 
someone with bigger gun.  Most systems that aren't compromised are those that do 
not draw attention, mostly because of their insignificance.

> IMHO we want the supplier of a given firmware providing signatures on the 
> firmware git tree if this is done. A generic linux-firmware owned key would be 
> both a horrendously inviting attack target, and a single point of failure.
>
> Git can already do all the needed commit signing bits unless I'm missing 
> something here ?

If i read the above correctly you propose to have a tree where all binary blobs 
(or whatever data) will be trusted, because their authenticity will be verified 
prior to their inclusion?  By cloning this tree i should also trust its content 
because GIT takes care of data's integrity?


		Petko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/