Thank you very much for answers! I re-read the development guide, but it's hard to swallow for the uninitiated...
See replies below > On 03 May 2016, at 11:34, martin.wi...@ts.fujitsu.com wrote: > > 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? > I misunderstood this one obviously. So I want to use a signed policy, and use multiple policy data files for lifecycle management (e.g. when I need to upgrade to MLE but want to be able to "rollback" to a previous version if needed). Using a signed policy means I don't have to touch the NVRAM (which might break something, making rollback impossible). Sounds right? >> 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. Exactly what I need. > > 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. So that's what it is for :-) I wondered what --ctrl bits were and din't think of looking in the dev guide... > >> - 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. Is it simply something like: lcp_crtpolelt --create --type custom --uuid tboot --out vlp.elt vlp.dat and then add it vlp.elt to lcp_crtpollist when creating the LCP? This is great for my lifecycle management, I don't want to touch NVRAM after bootstrapping the system, and this way I can even sign everything off-site and distribute. (Otherwise the obvious attack vector would be to get the TPM password when upgrading/provisioning, this alleviates that completely). > >> - 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. > pcr_map=da sounds excellent for my use, thanks! > 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. If one can get into SMM then there's not much we can do. I'm more worried about vendor TPM implementations (e.g. how easy it is to attack the TPM directly) or in TXT implementation in the platform. I just got a new development system (ThinkCentre M900) and everything I touch is somewhat buggy. I enabled TXT and the system just hanged in BIOS until i did CMOS reset via jumper. Next try it booted. Then I enabled Intel ME and it hanged again. CMOS reset -> booted. Disabled PXE -> hang. CMOS reset... I had to reset BIOS like 20 times while enabling the features I need to even get it to boot, and I haven even touched TXT or ME, so it's b0rked pretty much out of box. And Intel ME is a story for itself - "lsusb -v" when KVM is connected causes the ME to crash completely, what the... And I'm supposed to trust that TXT is implemented correctly? All those features are neat and all, but is anybody actually using them? That's my biggest worry... Jan > > >> >> 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 ------------------------------------------------------------------------------ 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
