boot1.efi future

[Eric McCorkle]

Keeping it short, I've got a bunch of plans in this area. I was actually planning to finish off a paper and put it up for discussion this weekend. I'll talk more about it elsewhere. 

On October 20, 2017 1:05:51 AM EDT, "Simon J. Gerraty" <sjg at juniper.net> wrote:
>Eric McCorkle <eric at metricspace.net> wrote:
>> > I've implemented verification in the freebsd loader, along the
>lines
>> > previously mentioned, for us this pretty much closes the
>secure-boot
>> > gap - loader verifies kernel and its initial rootfs so init and
>etc/rc.
>> > Which then gets us to mac_veriexec.
>> 
>> Do I assume correctly that this is based on the NetBSD mac-based
>> verification stuff?  ie. Not the public-key crypto stuff I've talked
>about?
>
>I didn't want to thread-jack...
>
>I've not looked at what's in NetBSD in this area for a decade at least,
>but I ported the original veriexec from NetBSD to Junos about a dozen
>years or so ago.  More recently stevek re-implemented it for FreeBSD
>10's MAC framework - the diffs (most of them anyway) have been sitting
>in phabricator for a year or so...
>
>The loader implementation shares no code with the above, but uses the
>same verification model and leverages the same signed manifests.
>Thus it retains all the flexibility of using X.509 certificate chains
>to
>verify the signatures on the manifests.
>
>This is very important for us, because it allows a 10 year old binary
>to
>verify the latest signatures - provided that the RootCA certs have not
>changed. For Junos the loader knows two RootCA's one for RSA and one
>for
>ECDSA - that's all it needs.
>
>We can tollerate more limited signing methods for the loader itself, to
>fit in to various secure BIOS/boot environments, but from there we want
>all the flexibility we can get.
>
>--sjg

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.