Re: Should we automatically generate a module signing key at all?

[Andy Lutomirski]

On Tue, May 19, 2015 at 11:08 AM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> On Tue, 2015-05-19 at 10:58 -0700, Andy Lutomirski wrote:
>>
>> Throwing away the key is outright impossible in some contexts.
>>
>> https://wiki.debian.org/ReproducibleBuilds
>
> Are any of the benefits described at
> https://wiki.debian.org/ReproducibleBuilds/About *not* just as
> achievable with the method I suggested â where you throw away the key
> and just validate that your builds are identical *except* for the
> signatures... which you can reuse, since your builds were identical.

Yes, blatantly.  Quoting that link:

Should reproducible uploads become mandatory, then the incentive of an
attacker to compromise the system of a developer with upload rights is
lowered because it is not anymore possible for the developer to upload
a binary that does not match the uploaded sources.

In the context of a kernel, this means that I shouldn't have to trust
the machine that actually generated the binary.  In principle, I
shouldn't even need to trust the person who generated the package,
since the package should be easily comparable to kernel.org sources.

With your proposal, I need to trust that whoever built the actual
running kernel image really did throw away the key.  If they didn't,
then under whatever threat model requires that I enable module
verification, I'm screwed -- the bad guy has the private key.

The actual runtime code needed to implement a hash tree solution is
maybe twenty lines.  The bzImage will be smaller, and the modules will
be smaller (although the latter is only true because the current
scheme is bloated).  The only tricky part is getting the build process
to work.

--Andy
--
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/