Hi Lukasz, Thanks for taking a look, I know it is a lot to ask. When looking at the patches I'm mostly concerned about feedback on the general concepts at this stage; the patches are still very much a work in progress. My goal in posting this on-list was to get some feedback now to see if this is something that would be of interest to the project. I would hate to spend a few more months on this only to find out that tboot has not interest in signature verification :)
As far as changes to the VLP are concerned, if you look at the patch titled "tboot: add PECOFF signature verification hooks" you will see that two of the TODO items are ... - Support for kernel signature verification in the tboot policy. This probably means specifying a signing certificate as part of the policy. We want to support certificate chains. Backwards compatibility is a must. - If the tboot policy can not be easily extended to support signature verification, we could consider embedding the certificate into the tboot binary at build time, similar to what is done with the UEFI Secure Boot shim. I would obviously prefer to add a signing certificate or CA to the VLP, but I haven't done enough investigation into the VLP format to know if that is practical. As a fallback I could envision embedding the certificate into the binary (as the current prototype does), but that is something I would like to avoid if possible. As far as attestation and PCR values are concerned, my current thought is to hash the signing certificate into one PCR (say PCR A) (assuming the kernel signature is valid) and a combined hash of the kernel/initrd/cmdline into a different PCR (say PCR B). My thinking is that this would allow admins to seal/attest to either a specific kernel/initrd/cmdline using PCR B or to the signing authority which has validated the kernel/etc. using PCR A. However, I am open to other ideas if you have suggestions - this effort is still in the early stages. This is one of the reasons I wanted to bring this effort to the list as soon as the basic idea (PECOFF signature verification in tboot) was working. Thanks again, -Paul On Fri, 2019-09-27 at 13:43 +0200, Lukasz Hawrylko wrote: > Hi Paul > > Thank you for sharing your work. I will look at this patch and check > how > it works, idea of measuring kernel signature instead of whole binary > is > very interesting. I hope that next week I will find some time for > that, > as you said patch is quite big. > > Do you plan to add ability to verify public key using VLP? If I > understand correctly your current goal is to verify kernel binary with > signature and extend PCRs with signature's public key hash, am I > right? > In this approach tboot is not able to verify if kernel is signed by > proper authority, this need to be done be local/remote attestation in > further boot process. > > Thanks, > Lukasz > > On Thu, 2019-09-19 at 15:39 +0000, Paul Moore (pmoore2) via tboot- > devel > wrote: > > Hello, > > > > I've been working on adding PECOFF/kernel signature verification to > > tboot and now that I have a rough working prototype I wanted to > > bring > > it to the list to see if this is something the tboot community would > > be interested in eventually merging (once the work is more complete > > and polished). > > > > The patchset is quite large, mostly due to the inclusion of > > libtomcrypt and libtomfastmath to the tboot repository, so I'm going > > to refrain from spamming the list with the full patchset at this > > early > > stage. The current patchset can be found on GitHub at the URL below > > (look in the "working-txtsig" branch): > > > > * > > https://github.com/pcmoore/misc-tboot/tree/working-txtsig > > > > > > The prototype doesn't actually enforce any policy or change the PCR > > measurements based on the kernel signatures (both are planned work > > items), but it does demonstrate the ability to parse and verify a > > signed PECOFF image. The individual patch descriptions provide some > > additional information on some of the planned work to take this from > > a prototype to a proper implementation. > > > > My motivation for this work is to create a mechanism that is capable > > of generating a stable set of PCR values across multiple kernels > > that > > can be used to seal TPM NVRAM secrets on both legacy BIOS and UEFI > > systems. Imagine being able to store a storage encryption key in > > the > > TPM, and restricting access to that key to only authorized kernels > > in > > such a way that didn't require changing the tboot policy when > > booting > > different kernels. I imagine I'm not along in thinking this would > > be a nice capability to have, especially on systems that don't > > support > > UEFI Secure Boot. > > > > For those who are interested, I gave a presentation on this work at > > the Linux Security Summit last month, the video and sldies are > > available at the links below: > > > > * > > https://www.youtube.com/watch?v=Qbjz_5jUE9o > > > > * > > https://www.paul-moore.com/docs/lss-securing_tpm_with_txt-pmoore-201909-r2.pdf > > > > > > Thoughts? Is this capability something the TXT/tboot community > > would > > be interested in merging into the main tboot repository once it is > > more complete? > > > > _______________________________________________ > > tboot-devel mailing list > > tboot-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/tboot-devel > > > > _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
