On Fri, 2019-10-18 at 13:27 +0000, Paul Moore (pmoore2) via tboot-devel wrote: > 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 ...
Hello everyone, I just pushed another update to my git repository under the working- txtsig branch: * https://github.com/pcmoore/misc-tboot/tree/working-txtsig This update is notable in that it adds the missing policy support; no longer is the Fedora CA built into the tboot binary, verification certificates should be included in the LCP and the tboot VLP specifies which modules are subject to signature verification. While there is still work to be done, I believe the code is now feature complete (or very close to it). I would appreciate sanity checks on my approach, especially when it comes to the policy changes. The commit descriptions have additional information, but in order to include certificates in the LCP, you would do the following: # lcp2_crtpolelt --create \ --type custom --uuid certificates test.der \ --out test.elt ... in this case test.der is a DER encoded X509 certificate; multiple certificates may be concatenated together into the file, tboot will load each certificate. Once the policy ELT has been created, it can be included in the LCP just as you would any other ELT module. Once you have created a certificate ELT, you need to tell the tboot VLP to perform PECOFF signature verification on the kernel module; you can do that with the following command(s): # tb_polgen --create --type nonfatal test.vlp # tb_polgen --add --num 0 --pcr 20 --hash pecoff test.vlp # tb_polgen --show test.vlp policy: version: 2 policy_type: TB_POLTYPE_CONT_NON_FATAL hash_alg: TB_HALG_SHA1 policy_control: 00000001 (EXTEND_PCR17) num_entries: 1 policy entry[0]: mod_num: 0 pcr: 20 hash_type: TB_HTYPE_PECOFF num_hashes: 0 ... the pecoff/TB_HTYPE_PECOFF hash type instructs tboot to perform PECOFF signature verification on the given module. When selected, the digest of the trusted root for the signing authority will be extended into the given PCR, which happens to be PCR 20 in the example above. As a point of clarification, the "trusted root" is not necessarily the root CA of the signature chain, but rather the "nearest" certificate that was loaded from the LCP which is part of the signature chain. This should provide for the most flexibility while preserving a signature root of trust in the LCP/TPM. Comments and feedback on this approach are encouraged! -Paul _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
