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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150522124246.25531.qmail@ns.horizon.com>
Date:	22 May 2015 08:42:46 -0400
From:	"George Spelvin" <linux@...izon.com>
To:	linux@...izon.com, luto@...capital.net
Cc:	dhowells@...hat.com, dwmw2@...radead.org,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, petkan@...-labs.com,
	torvalds@...ux-foundation.org, tytso@....edu,
	zohar@...ux.vnet.ibm.com
Subject: Re: Should we automatically generate a module signing key at all?

Andy Lutomirski wrote:
> Bonus exercise for the reader: find the security hole in this
> simplified scheme :)  Hint: you can construct a proof of validity for
> a sequence of bytes that isn't a module at all.

Well, does the kernel store the number of levels in the hash tree along
with the hash, or believe the module?

The other practical issue is whether 2x256 bits = 64 bytes of concatenated
hashes can look enough like an ELF header to be loaded.  Or contain
enough payload do anything "interesting".

But that sort of cheap trick is putting the ELF header parsing on the
front lines (i.e. it's now part of the attack surface).  I fully agree
that it's bad crypto design and the crypto should fully validate
the input before passing it on.

>> Andy, an easier indexing scheme might use, instead the depth
>> and index separately, the implicit heap numbering.  The root is
>> node 1, its children are 2 and 3, their children are 4 through 7, etc.

> That could work, too.  I think it kills my xor-1 trick, though.

Not at all; if anything it's inspired by the xor-1 trick.  It works
exactly the same, you just omit the level beccause it's derivable from
i^1, i>>1^1, i>>2^1, etc.

All you're doing is storing (i | 1<<level).  The position of the msbit
gives the level, while the lsbits are unmodified, so the XOR trick is
also unmodified.

> Long-term, I think it would be neat if NIST standardized something
> like the Sakura tree coding system, and we'd just use that.

> (It would be extra neat if they standardized an encoding of Sakura proofs,
> but I'll take a standard and correct hash tree as a very good start.)

It would also take some hacking on the spec to cover hashing separate
messages; Sakura is specified to cover various ways of breaking up a
single message into pieces which are logically concatenated.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/