Re: [tboot-devel] [RFC] tboot: kernel signature verification
Hi Lukasz, I'm happy to join the internal discussion if you think it would be helpful, although I do have some travel scheduled for later this month. Feel free to contact me off-list if you want to discuss timing. Are you going to be at Linux Security Summit EU in France at the end of October? Thanks for taking the time to give the patch a quick look/test. While I've tested a handful of CentOS-7.x and Fedora 5.x kernels (NOTE: CentOS-7.x and modern Fedora use a slightly different signature format), I haven't tried signing my own kernel yet, but obviously that is something that needs to work. My guess is that Fedora/CentOS/RHEL uses a technique similar to what you are using in your example so it *should* work, but you've obviously hit a problem. Since the code is still in the "barely works" prototype stage I'm not going to worry about this too much at the moment, but I will look into it before I submit the patchset for inclusion, as opposed to the current RFC patchset. FWIW, I'm currently working on getting certificate chains working. The code can now parse certificates into a crude certificate db, and I'm currently sorting out the certificate signature verification. Once I get the certificate chain support working, I plan to start looking at the policy. As we've previously discussed, hardcoding the certificate into the tboot binary is an option of last resort. Beyond that, I think the options are wide open; I had always assumed that we would likely need to store the certificate in the LCP portion of the policy that is stored outside of the TPM. So long as the policy can be verified by a TPM based root of trust (which is what currently happens with the LCP from what I can see) there shouldn't be a problem). -Paul On Tue, 2019-10-08 at 14:18 +0200, Lukasz Hawrylko wrote: > Hi Paul > > We are going to have internal discussion about this feature in two > weeks, I have to prepare some presentation, so be prepare for > questions > in near future :) > > I have built version with your patch, looks like verification is > working > with Fedora's kernel indeed. However I was not be able to verify > kernel > signed with my testing certificate, did you try that? TBOOT is hanging > on: > > TBOOT: >>> DBG/SIG: mod[0], pkcs7 parsing > > I guess that pkcs7_signeddata_parse can't read kernel signature, if > you > want to test it by yourself here are commands that I was using: > > openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 \ > -sha256 -days 3650 -subj "/CN=my Signature Database key/" \ > -out db.crt > openssl x509 -outform DER -in db.crt -out db.cer > sbsign --key db.key --cert db.crt --output bzImage_signed bzImage > > Adding certificate to VLP has one major disadvantage - VLP is stored > in > TPM NV that has very limited space. Putting ~1kB certificate there is > in > my opinion bad idea. I would suggest to implement the same mechanism > as > we already have for LCP. Certificate will be stored on disk and will > be > passed to TBOOT using multiboot2 protocol. In VLP there will be only > hash of that file, so TBOOT will be able to verify if certificate is > valid. Storing another hash in VLP is not a problem. What do you think > about that? Hardcoding certificate in TBOOT should be avoided at all > costs. > > Thanks, > Lukasz > > On Fri, 2019-09-27 at 15:35 +, Paul Moore (pmoore2) wrote: > > 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
Re: [tboot-devel] [RFC] tboot: kernel signature verification
Hi Paul We are going to have internal discussion about this feature in two weeks, I have to prepare some presentation, so be prepare for questions in near future :) I have built version with your patch, looks like verification is working with Fedora's kernel indeed. However I was not be able to verify kernel signed with my testing certificate, did you try that? TBOOT is hanging on: TBOOT: >>> DBG/SIG: mod[0], pkcs7 parsing I guess that pkcs7_signeddata_parse can't read kernel signature, if you want to test it by yourself here are commands that I was using: openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 \ -sha256 -days 3650 -subj "/CN=my Signature Database key/" \ -out db.crt openssl x509 -outform DER -in db.crt -out db.cer sbsign --key db.key --cert db.crt --output bzImage_signed bzImage Adding certificate to VLP has one major disadvantage - VLP is stored in TPM NV that has very limited space. Putting ~1kB certificate there is in my opinion bad idea. I would suggest to implement the same mechanism as we already have for LCP. Certificate will be stored on disk and will be passed to TBOOT using multiboot2 protocol. In VLP there will be only hash of that file, so TBOOT will be able to verify if certificate is valid. Storing another hash in VLP is not a problem. What do you think about that? Hardcoding certificate in TBOOT should be avoided at all costs. Thanks, Lukasz On Fri, 2019-09-27 at 15:35 +, Paul Moore (pmoore2) wrote: > 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 +, 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 > > >
