On 03/29/2017 09:54, Michael Richards wrote: >> 1) Be able to check for a correct cryptographic signature for any kernel >> or modules loaded at boot time for some platforms (EFI at a minimum). > > 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) > >> 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) > > 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. > 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... > > 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 scheme > here is a bit complicated. Once an executable or library is produced and > 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. > > As an extension to this idea, it would be interesting if a database of > exploitable system .exe and libraries were maintained. It would be handy > 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.
signature.asc
Description: OpenPGP digital signature
