Hi All,

On Wed, May 20, 2015 at 6:59 AM, Andy Lutomirski [off-list ref] wrote:

[added cc's from the other thread]

On 05/19/2015 01:02 PM, Luis R. Rodriguez wrote:

quoted

David Howells has posted v4 of his series of supporting PKCS#7 for module
signing. I'm in my v3 series now on RFCs for firmware PKCS#7 support, and
after
some review and patch shuffling I think this is ready for patch form.  My
own
series however depend on quite a bit of other pending changes, one series
which
will go through Rusty's tree, another series of fixes on firmware_class
which
should go through Greg's tree. I'll wait until all this and David's own
patches
get merged before posting firmware PKCS#7 support. Before all this though
in
preparation for fw signing one thing we should start to talk about more
broadly
however is how linux-firmware binary file signing would work in practice
and
what we need, and make sure folks are OK with all this.

First, firmware signing will be completely optional as with module
signing.

...

quoted

Other than this last nitpick, any other concerns or recommendations ?

A couple.  Some of these are general concerns with the existing
infrastructure, but #1 is a specific problem that gets much worse if we add
firmware signing.  Feel free to ignore 2-4.

1. We should get the signature semantics right.  I think that, for modules,
we currently sign literally the module payload.  For modules, in my
semi-amateurish crypto universe [1], this is fine *as long as the key in
question is used for no other purpose*.  For firmware, it's dangerous, since
it would be vulnerable to substitution attacks in which the adversary
convinces us to interpret one firmware file as firmware for another device
or purpose entirely.

We should be signing something that's semantically equivalent to "This is a
valid module: xyz", "This is a valid 'regulatory.bin': xyz", or "This is a
valid kexec image: xyz".

Something that occurred to me (as a complete bystander) was: would it
make sense to have keys able to be restricted to particular "types" of
signable data? I.e. the key that can sign a valid regulatory.bin file
cannot be used to sign a module or a kexec image. - This could remove
the need to have multiple keyrings. (Also, UEFI keys unless otherwise
tagged could be restricted to only signing bootloaders or kernels)

Also, are multiple signatures a sensible thing? E.g. regulatory.bin
gets signed by Seth, then Kyle, then $DISTRO and any one key is enough
to validate it.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/