On Fr, 2016-04-29 at 12:27 +0200, Jan Schermer wrote: > Hello, > can someone confirm my understanding and clarify my questions, please? > > 1) Launch control policy > - protects tboot integrity (MLE) > - can limit boot to certain PCRs > - can I have multiple generations of LCPs if I need to upgrade tboot or > change a PCR? > > >From my understanding, if I use an empty signed policy, I can have multiple > >policy data files signed by the same key with different policies. Is that > >so? Does it work in practice?
My understanding is: you can have one policy file with several policy lists defining different policies. http://www.intel.com/content/www/us/en/software-developers/intel-txt-software-development-guide.html has the details (§3.2.8) IMO it makes little sense to have multiple OR'd policies. Every policy element allows to specify multiple allowed values (for example, different tboot versions in the MLE element). The only valid case of two policies which I can think of is the combination of signed and unsigned policy as shown in the tboot docs. But, once you have set up the infrastructure for policy signing, for what reason would you still want to maintain the unsigned policy? > 2) Verified launch policy (tboot) > - verifies "modules" (usually vmlinuz, initramfs) and measures them > into PCRs of my choosing > - limits boot to modules in the policy > - does it? Can a platform contain some default policy that > would allow circumventing this lock? If an attacker has access to the boot loader menu and/or the BIOS setup, and is thus able either to boot without tboot or to disable TXT in the BIOS, he would be able to boot the system. However this system would be running without TXT. If data was sealed against a TXT-related PCR, the attacker would be unable to retrieve that data. Platform Supplier policy is usually of type ANY, whereas any reasonable Platform Owner policy will be of type LIST. In this case, only the PO policy will be evaluated. In the unlikely case that there actually is a PS policy of type LIST, whether or not it is considered in the presence of a PO policy is determined by the "Ignore_PS_EltType" bit in the PolicyControl field, which you can set with the --ctrl flag of the lcp_crtpol2 tool. See TXT development guide §3.2.2, §3.2.8.2. > - needs to be written to NVRAM on every change There are two ways to install the VLP - either in NVRAM (in which case you're right) or by simply adding it to the LCP as a "custom" element. If you do the latter, and use signed LCP, you don't need to update the NVRAM after a kernel update. You would just update the VLP element integrated in the LCP, and sign the updated LCP. > - I don't like this much, I'd prefer a mechanism like Secure > Boot where I'd put my CA key in the VLP and whatever is signed gets booted, > and the CA key would be extended into PCR18 for example. Is something like > this possible? > > 3) I the end I need to be able to unseal data only in the TXT environment > when my OS is booted, and I'd like to avoid resealing the secrets to every > new VLP module combinations Use pcr_map=da and use PCR 18 (which is invariant against policy updates) for sealing. Use a VLP of type "halt", so that the system will fail to boot into TXT unless the kernel and initrd are successfully validated. In this case you can be certain that the only setup where the system is up and PCR 18 is valid is a valid TXT environment. Regards Martin PS: This says nothing about the potential ability of attackers to subvert TXT itself (see http://invisiblethingslab.com/resources/bh09dc/Attacking%20Intel%20TXT% 20-%20slides.pdf). But that would hold for other similar technologies likewise. > > Can I simply seal the data to only PCR 17 then? > To break the seal someone would need to either > a) know the TPM password and change the VLP to boot another OS > b) reset the TPM in BIOS > - but this should clear the old SRK, os my sealed data can't be > unsealed anymore - can I rely on this? > c) some other attack vector I'm not aware of? > - OS will be encrypted so that vector is not possible > > Thanks > > Jan > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > tboot-devel mailing list > tboot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tboot-devel ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
