Date: Wed, 29 Mar 2017 10:27:46 -0400 From: Eric McCorkle <eric@metricspace.net> To: Michael Richards <michael@fastmail.ca>, freebsd-security@freebsd.org Subject: Re: Proposal for a design for signed kernel/modules/etc Message-ID: <9a26934a-613e-a4fa-7f27-5e1c35f5bb8c@metricspace.net> In-Reply-To: <1490795691.3691150.927389880.305FD2A4@webmail.messagingengine.com> References: <mailman.52.1490702401.61780.freebsd-security@freebsd.org> <1490795691.3691150.927389880.305FD2A4@webmail.messagingengine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6Wv53SlISK8R4vMeTAbKvx2kDHNtv3TF8 Content-Type: multipart/mixed; boundary="FU6BXL3r0HquNG4efSAVX0x94ksOFRulV"; protected-headers="v1" From: Eric McCorkle <eric@metricspace.net> To: Michael Richards <michael@fastmail.ca>, freebsd-security@freebsd.org Message-ID: <9a26934a-613e-a4fa-7f27-5e1c35f5bb8c@metricspace.net> Subject: Re: Proposal for a design for signed kernel/modules/etc References: <mailman.52.1490702401.61780.freebsd-security@freebsd.org> <1490795691.3691150.927389880.305FD2A4@webmail.messagingengine.com> In-Reply-To: <1490795691.3691150.927389880.305FD2A4@webmail.messagingengine.com> --FU6BXL3r0HquNG4efSAVX0x94ksOFRulV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/29/2017 09:54, Michael Richards wrote: >> 1) Be able to check for a correct cryptographic signature for any kern= el >> or modules loaded at boot time for some platforms (EFI at a minimum). >=20 > I think it would be valid to have a boot from write protected device > (USB key) that does the initial kernel check and load and maybe stores > the keychain. There's a couple of use cases I envision: 1) EFI solution: Build a verification key (see my response to Shawn Webb for a discussion on vendor/application keys) into loader.efi, and set up EFI secure boot with boot1.efi and loader.efi. The EFI Secure Boot framework checks signatures on boot1.efi and loader.efi (since boot1.efi uses EFI API calls to load loader.efi). Then loader.efi does the signature check as I've proposed. 2) GRUB solution: GRUB would need to be patched to use the scheme I've proposed; however, the rest is all existing GRUB functionality: you can establish a trust key in the GRUB config file and configure GRUB to enforce signature checks. You could boot from EFI secure boot, or you could install GRUB as a coreboot payload (the coreboot payload is the solution I'm planning for myself). I suppose you could also engineer more exotic solutions like having keys on a separate USB dongle, but I'd want to aim for the basics at first. (Some of my other pending work might help with this, actually) >=20 >> 7) The design must allow for the adoption of new ciphers (there is an >> inevitable shift to post-quantum ciphers coming in the near future) >=20 > Despite peoples' dislike of paying for keys, there is already a system > in place for vendors to pay for authenticode keys. It would be nice if > this were also supported. This way, my company can maintain the > authenticode keys we already pay for and if a FreeBSD binary were > produced we could use the existing infrastructure to sign them without > the need to introduce yet another key to manage. >=20 Do authenticode keys come in a standard format known by OpenSSL, or can they be converted to one? It seems like what you really want is to be able to use a key that some trust authority has signed; that should be achievable as long as you can convert to a format that tools in base can recognize. Depending on the key size and ciphers, though, it might be wise to have some kind of ALLOW_WEAK_CRYPTO option. Microsoft does has a history of using weak ciphers and short keys... >=20 > I think it will be important to consider a backward and forward > compatible format for your sections. XML is too big to audit a parser, > but something simple and parseable with a version number and such would= > be good. Suppose a security flaw is found, then you should be able to > configure the acceptable signing scheme/version. I also think the schem= e > here is a bit complicated. Once an executable or library is produced an= d > installed on my machine I don't know that there is or should be any > legitimate need to modify or re-order the contents. Just make the file > and sign it. If it's modified, I want to know! The simpler the > solution, the easier to implement, test and audit. Note that I walked this back to just signing the whole executable after Shawn Webb's response. >=20 > As an extension to this idea, it would be interesting if a database of > exploitable system .exe and libraries were maintained. It would be hand= y > as an admin to have an immediate report that library XYZ on your system= > is exploitable and needs your attention. That sounds like portaudit more or less for binaries. It's an interesting idea, but I think it's a separate effort. --FU6BXL3r0HquNG4efSAVX0x94ksOFRulV-- --6Wv53SlISK8R4vMeTAbKvx2kDHNtv3TF8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEzzhiNNveVG6nWjcH1w0wQIFco2cFAljbxGIACgkQ1w0wQIFc o2cc9hAAkd3ux5hQzGmx1rlTZs4n1rJXmuoLzE8ZExzNnV2qexI6HXOZqE7pUIvD xFuZPfFlVxKOOaWzt+XzEXe9wD3SrmfrmomMvUyN+L8ptUZekuEi6+5qe4gI59aE H4T/8N798qn47yxjFx27pRjnAyJxVyXONRglAbHXyP/nAdYE3DeaNuRz0FP87Hwr tu4sVKqH1F5m1YPpCThiIExhqPENSBjj92b41qEj3lOY57K2fH0FEz2jOZ2WD/QA wPWsVRDOeEZjEIrh0x32V35O22LPdoK/l+/XTCsSjyxn9yaqkMoExHoHUNDiiqMe 4vMR0J2pJERpvt8mLScTcVz+7tla7jJZl51nHFBAxhEP7CKMdWB3QGWzHK6Pv0I6 zPNCZcuRFH3XafgonDldZDer3W+1ejuJtpw9FlBKDYtpvDfC05XI9A2uDy9NZfcw K3YgUNsgXRqiTvRm+EykdEug6nL3V3KlexIGe8+md7bwRQK8bbQp/T8bvK44DvfB Xt702PJ3u2oRucuATIPydaw4Fz1kswYiMDtsP+bK53AdvVElMWBACHkXxDTrc9PF /bsLe2ysetTdXofzrIViRLW9y0pZgxfGWl0u06okTRDq3oY3TLmU55oKXRXJpDIP SCliYvqiDh0Az7wQKBfCBumATEOITuCM7JhlBonBU+liQlurcuQ= =vaCT -----END PGP SIGNATURE----- --6Wv53SlISK8R4vMeTAbKvx2kDHNtv3TF8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9a26934a-613e-a4fa-7f27-5e1c35f5bb8c>