Trust system write-up

Eric McCorkle eric at metricspace.net
Tue Oct 24 00:00:55 UTC 2017


On 10/23/2017 18:53, Simon J. Gerraty wrote:
> Eric McCorkle <eric at metricspace.net> wrote:
>>> Any thoughts on how to validate executables which are not elf binaries,
>>> such as shell scripts, python programs, etc?
>>
>> I hadn't really thought in depth about it, as my main initial goal is
>> signed kernel/modules, but I have given it some thought...
>>
> 
>> An alternative is something like the NetBSD veriexec framework, where
> 
> Yes, as previously mentioned the verified exec model deals with this
> neatly, and btw is more efficient than signing individual files - as is
> needed with ELF signing etc.  I think for linux based platforms using IMA we
> need to generate 20-30k+ signatures, vs about a dozen for platforms using
> verified exec, verification is also more expensive I'm told.

Hmmm.  There's advantages both ways, and I'll probably end up supporting
both, as it's useful to have an in-band mechanism as well (also, I've
already implemented signed ELFs).

However, there is a definite advantage to having one signature for a
huge number of MACs.  Moreover, as I mention in the paper, the most
feasible quantum-safe signature scheme at the present is SPHINCS, which
has signatures about 40Kib in size.  That's pretty terrible if you're
signing each executable, but if you're signing 20-30k MACs at 16-32
bytes per code plus a path, suddenly a 40Kib signature doesn't look so
bad anymore.  It would be pretty great to roll out a trust
infrastructure AND viable quantum-safe signatures.

I could also see a combined scheme, say, where ELF files carry a UUID
which indexes into a MAC manifest.


More information about the freebsd-arch mailing list